for CCE
indexes calculation to guarantee UEs in the same MBS group receiving the same
PDCCH.Please refer to RP-201038 for detailed scope of the WI
R1-2006232 NR MBS work plan CMCC, Huawei, HiSilicon
R1-2007001 FL summary on NR Multicast and Broadcast Services Moderator (CMCC)
[102-e-NR-MBS-01] Email discussion/approval using R1-2007001 as a starting point, focusing on high-level aspects – Fei (CMCC)
R1-2007089 Summary#1 on NR Multicast and Broadcast Services Moderator (CMCC)
Agreements:
For RRC_CONNECTED UEs, HARQ-ACK feedback is supported for multicast and no additional evaluation is needed to justify this.
· FFS: The detailed HARQ-ACK feedback solutions, e.g., ACK/NACK based, NACK-only based.
· FFS: HARQ-ACK feedback can be optionally disabled and/or enabled.
R1-2007235 Summary#2 on NR Multicast and Broadcast Services Moderator (CMCC)
R1-2007341 Summary#3 on NR Multicast and Broadcast Services Moderator (CMCC)
Agreements:
For RRC_CONNECTED UEs, at least support group-common PDCCH with CRC scrambled by a common RNTI to schedule a group-common PDSCH, where the scrambling of the group-common PDSCH is based on the same common RNTI.
· FFS: whether to support UE-specific PDCCH to schedule a PDSCH for MBS.
Agreements:
For RRC_CONNECTED UEs, define/configure common frequency resource for group-common PDSCH.
· FFS: whether to reuse the BWP framework or not
· FFS: the relation between the common frequency resource and UE dedicated BWP, e.g., the common frequency resource is a MBS specific BWP, or the common frequency resource is confined within UE’s dedicated BWP, etc.
· FFS: whether more than one common frequency resource can be configured per UE
Agreements:
For RRC_CONNECTED UEs, at least support FDM between unicast PDSCH and group-common PDSCH in a slot based on UE capability.
· FFS: TDM or SDM in a slot.
Agreements:
For RRC_CONNECTED UEs, at least support slot-level repetition for group-common PDSCH.
· FFS: whether enhancement is needed
Agreements:
For RRC_CONNECTED UEs, existing CSI feedback can be used for multicast transmission.
· FFS: whether enhancement is needed
Focus on high-level concepts for group scheduling mechanism
R1-2005249 Resource configuration and group scheduling for RRC_CONNECTED UEs Huawei, HiSilicon
R1-2005406 Discussion on mechanisms to support group scheduling for RRC_CONNECTED UEs vivo
R1-2005436 Mechanisms to Support Group Scheduling for RRC_CONNECTED UEs ZTE
R1-2005531 Group Scheduling Mechanisms to Support 5G Multicast / Broadcast Services for RRC_CONNECTED Ues Nokia, Nokia Shanghai Bell
R1-2005589 Considerations on MBMS group scheduling for RRC_CONNECTED UEs Sony
R1-2005693 Discussion on group scheduling mechanism for RRC_CONNECTED UEs in MBS CATT
R1-2005898 Group Scheduling for NR-MBS Intel Corporation
R1-2006013 Group scheduling for NR Multicast and Broadcast Services OPPO
R1-2006173 On Mechanisms to support group scheduling for RRC_CONNECTED UEs Samsung
R1-2006233 Discussion on group scheduling mechanisms in NR MBS CMCC
R1-2006320 Support of group scheduling for RRC_CONNECTED UEs LG Electronics
R1-2006631 On group scheduling mechanism for NR multicast and broadcast Convida Wireless
R1-2006830 Views on group scheduling for Multicast RRC_CONNECTED UEs Qualcomm Incorporated
R1-2006918 Mechanism for group scheduling of RRC_CONNECTED UEs in NR Ericsson
Focus on high-level concepts for required changes to improve reliability of Broadcast/Multicast service, e.g. by UL feedback.
R1-2005250 Mechanisms to improve reliablity for RRC_CONNECTED UEs Huawei, HiSilicon
R1-2005407 Discussion on mechanisms to improve reliability for RRC_CONNECTED UEs vivo
R1-2005437 Mechanisms to Improve Reliability for RRC_CONNECTED UEs ZTE
R1-2005532 Mechanisms for 5G Multicast / Broadcast Reliability Improvements for RRC_CONNECTED Ues Nokia, Nokia Shanghai Bell
R1-2005590 Considerations on MBMS reliability for RRC_CONNECTED UEs Sony
R1-2005694 Discussion on reliability improvement mechanism for RRC_CONNECTED UEs in MBS CATT
R1-2005899 Mechanisms to Improve Reliability for NR-MBS Intel Corporation
R1-2006014 UL feedback for RRC-CONNECTED UEs in MBMS OPPO
R1-2006174 On Mechanisms to improve reliability for RRC_CONNECTED Ues Samsung
R1-2006234 Discussion on reliability improvement in NR MBS CMCC
R1-2006321 Mechanisms to improve reliability of Broadcast/Multicast service LG Electronics
R1-2006632 On reliability enhancement for NR multicast and broadcast Convida Wireless
R1-2006831 Views on UE feedback for Multicast RRC_CONNECTED UEs Qualcomm Incorporated
R1-2006863 HARQ-based time-interleaving for NR Multicast/Broadcast BBC
R1-2006919 Mechanisms to improve reliability for RRC_CONNECTED UEs receiving PTM transmission Ericsson
A placeholder - no plan to treat during this meeting
R1-2005272 Discussion on multicast support for IDLE/INACTIVE UEs Huawei, HiSilicon
R1-2005408 Discussion on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs vivo
R1-2005438 Basic Functions for Broadcast or Multicast for RRC_IDLE or RRC_INACTIVE UEs ZTE
R1-2005533 Basic Functions for Broadcast / Multicast for RRC_IDLE / RRC_INACTIVE Ues Nokia, Nokia Shanghai Bell
R1-2005695 Discussion on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs CATT
R1-2006015 Discussion on enhancements for IDLE and INACTIVE state UEs OPPO
R1-2006175 On Basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs Samsung
R1-2006235 Discussion on NR MBS in RRC_IDLE RRC_INACTIVE states CMCC
R1-2006322 Basic function for broadcast/multicast LG Electronics
R1-2006832 Views on group scheduling for Multicast RRC_IDLE/INACTIVE UEs Qualcomm Incorporated
R1-2006920 Basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs Ericsson
R1-2005439 Preliminary Simulation Results of Rel-17 MBS ZTE
R1-2005534 Simulation assumptions and evaluation scenarios for 5G Multicast Services Nokia, Nokia Shanghai Bell
R1-2006016 PUCCH resource allocation for UL feedback in MBMS OPPO
R1-2006236 On R17 NR MBS WI CMCC
R1-2006410 Performance evaluation of HARQ for NR multicast Huawei, HiSilicon
R1-2006658 Other issues for Rel-17 MBS vivo
R1-2006861 MIMO support in NR Multicast/Broadcast BBC
R1-2006921 Assumptions for Performance Evaluations of NR-MBS Ericsson
Please refer to RP-201038 for detailed scope of the WI
R1-2008033 Updated NR MBS work plan CMCC
R1-2008034 Discussion on group scheduling mechanisms CMCC
Group scheduling mechanism:
· Proposal 1. For RRC_CONNECTED UEs, define following two PTM schemes only for discussion purpose.
o PTM scheme 1: For PTM transmission for UEs in the same MBS group, use group-common PDCCH with CRC scrambled by group-common RNTI to schedule group-common PDSCH which is scrambled with the same group-common RNTI. This scheme can also be called group-common PDCCH based group scheduling scheme.
o PTM scheme 2: For PTM transmission for UEs in the same MBS group, use UE-specific PDCCH with CRC scrambled by UE-specific RNTI (e.g., C-RNTI) to schedule group-common PDSCH which is scrambled with group-common RNTI. This scheme can also be called UE-specific PDCCH based group scheduling scheme.
· Proposal 2. For RRC_CONNECTED UEs, the configured common frequency resource for group-common PDSCH is confined within UE’s dedicated BWP, and the common frequency resource is configured per DL BWP.
· Proposal 3. For RRC_CONNECTED UEs and PTM scheme 1, if the common frequency resource is configured for the group-common PDSCH, the CORESET for the group-common PDCCH should be configured in the common frequency resource, and the FRDA field of group-common PDCCH is determined based on the common frequency resource instead of UE’s active DL BWP.
· Proposal 4. For PTM scheme 1, dedicated physical layer parameters for group-common PDSCH e.g., TDRA table, DMRS configuration, etc., can be configured under the configuration of common frequency resource.
· Proposal 5. Further discuss whether more than one common frequency resource can be configured per DL BWP.
·
Proposal 6. For PTM scheme
1, USS is preferred for group-common PDCCH monitoring,
but group-common RNTI value can be used in for CCE
indexes calculation to guarantee UEs in the same MBS group receiving the same
PDCCH.
· Proposal 7. For PTM scheme 1, both fallback DCI format 1_0 and non-fallback DCI format 1_1/1_2 could be considered with new interpretations.
· Proposal 8. Keep the “3+1” DCI size budget as in Rel-15/16 when PTM transmission is enabled.
· Proposal 9. For PTM scheme 1, decide whether the DCI size associated with group-common RNTI (G-RNTI) should be counted in the DCI size budget associated with C-RNTI or counted in the DCI size budget associated with all RNTIs.
· Proposal 10. For PTM scheme 1, keep the same maximum number of monitored PDCCH candidates and non-overlapped CCEs per slot per serving cell as in Rel-15 when R17 NR MBS is enabled.
· Proposal 11. For RRC_CONNECTED UEs, support PTM scheme 2 for NR MBS, i.e., UE-specific PDCCH with CRC scrambled by UE-specific RNTI to schedule group-common PDSCH scrambled with group-common RNTI.
· Proposal 12. The common frequency resource for group-common PDSCH can be optionally configured for PTM scheme 2. If type 0 frequency domain resource allocation is used, the RBG size and RBG numbering for FDRA indication in the UE-specific DCI are determined based on the size of common frequency resource instead of UE’s active BWP.
· Proposal 13. For PTM scheme 2, dedicated physical layer parameters for group-common PDSCH e.g., TDRA table, DMRS configuration, etc., can be configured under the configuration of common frequency resource.
· Proposal 14. For PTM scheme 2, non-fallback DCI format 1_1/1_2 could be considered, and one additional DCI field is defined to differentiate that the scheduled PDSCH’s scrambling initialization is based on UE-specific RNTI or group-common RNTI.
· Proposal 15. For PTM scheme 2, keep the same maximum number of monitored PDCCH candidates and non-overlapped CCEs per slot per serving cell as in Rel-15 when R17 NR MBS is enabled.
· Proposal 16. For NR MBS, if the initial transmission is based on PTM scheme 1, support that the re-transmission can be based on PTM scheme 1, PTM scheme 2 or PTP.
· Proposal 17. For NR MBS, if the initial transmission is based on PTM scheme 2, support that the re-transmission can be based on PTM scheme 2 or PTP.
Simultaneous operation with unicast:
· Proposal 18. For RRC_CONNECTED UEs, support TDM between unicast PDSCH and group-common PDSCH in a slot based on UE capability.
· Proposal 19. For RRC_CONNECTED UEs, support TDM between multiple group-common PDSCHs in a slot based on UE capability.
· Proposal 20. For RRC_CONNECTED UEs, support TDM or FDM between unicast PDSCH(s) and multiple TDMed group-common PDSCHs in a slot based on UE capability.
· Proposal 21. Further discuss whether to support FDM between multiple group-common PDSCHs in a slot for RRC_CONNECTED UEs.
· Proposal 22. Further discuss the PDSCH prioritization rule when PTM PDSCH is partially or fully overlapped in time in non-overlapping PRBs with another SI-RNTI PDSCH in one slot.
CA related issues:
· Proposal 23. Further discuss whether to consider the two typical CA cases in section 4.1 for R17 NR MBS.
Decision: The document is noted.
R1-2008940 Summary#1 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
R1-2007556 Group scheduling for MC/BC services FUTUREWEI
R1-2007562 Resource configuration and group scheduling for RRC_CONNECTED UEs Huawei, HiSilicon
R1-2007637 Group scheduling for RRC_CONNECTED UEs CHENGDU TD TECH LTD.
R1-2007691 Discussion on mechanisms to support group scheduling for RRC_CONNECTED UEs vivo
R1-2007835 Discussion on group scheduling mechanism for RRC_CONNECTED UEs in MBS CATT
R1-2008064 Support of group scheduling for RRC_CONNECTED UEs LG Electronics
R1-2008192 On mechanisms to support group scheduling for RRC_CONNECTED UEs Samsung
R1-2008242 Group scheduling for NR Multicast and Broadcast Services OPPO
R1-2008375 Considerations on MBMS group scheduling for RRC_CONNECTED UEs Sony
R1-2008449 Discussion on group scheduling mechanism for RRC_connected UEs Apple
R1-2008826 Mechanisms to Support Group Scheduling for RRC_CONNECTED UEs ZTE
R1-2008833 Discussion on mechanisms to support group scheduling for RRC_CONNECTED UEs ETRI
R1-2008882 Group Scheduling Mechanisms to Support 5G Multicast / Broadcast Services for RRC_CONNECTED UEs Nokia, Nokia Shanghai Bell
R1-2008926 Discussion on group scheduling mechanism for NR MBS Lenovo, Motorola Mobility
R1-2008961 Discussion on NR MBS group scheduling for RRC_CONNECTED UEs MediaTek Inc.
R1-2009000 Group Scheduling for NR-MBS Intel Corporation
R1-2009055 Discussion on mechanisms to support group scheduling for RRC_CONNECTED UEs Asia Pacific Telecom co. Ltd
R1-2009165 On group scheduling mechanism for NR multicast and broadcast Convida Wireless
R1-2009238 On Optimal Multiplexing for Simultaneous Operation of Broadcast/Multicast and Unicast Services BBC
R1-2009274 Views on group scheduling for Multicast RRC_CONNECTED UEs Qualcomm Incorporated
R1-2009305 Mechanisms to support group scheduling for RRC_CONNECTED Ues Ericsson
[103-e-NR-MBS-01] – Fei (CMCC)
Email discussion/approval for mechanisms to support group scheduling for RRC_CONNECTED UEs
R1-2009504 Summary#2 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
Decisions from GTW sessions,
Agreements: For convenience of discussion, consider the following clarification as RAN1 common understanding.
· PTP transmission: For RRC_CONNECTED UEs, use UE-specific PDCCH with CRC scrambled by UE-specific RNTI (e.g., C-RNTI) to schedule UE-specific PDSCH which is scrambled with the same UE-specific RNTI.
· PTM transmission scheme 1: For RRC_CONNECTED UEs in the same MBS group, use group-common PDCCH with CRC scrambled by group-common RNTI to schedule group-common PDSCH which is scrambled with the same group-common RNTI. This scheme can also be called group-common PDCCH based group scheduling scheme.
· PTM transmission scheme 2: For RRC_CONNECTED UEs in the same MBS group, use UE-specific PDCCH with CRC scrambled by UE-specific RNTI (e.g., C-RNTI) to schedule group-common PDSCH which is scrambled with group-common RNTI. This scheme can also be called UE-specific PDCCH based group scheduling scheme.
· Note: The ‘UE-specific PDCCH / PDSCH’ here means the PDCCH / PDSCH can only be identified by the target UE but cannot be identified by the other UEs in the same MBS group with the target UE.
· Note: The ‘group-common PDCCH / PDSCH’ here means the PDCCH / PDSCH are transmitted in the same time/frequency resources and can be identified by all the UEs in the same MBS group.
· FFS whether or not to have additional definition of transmission scheme(s)
Agreements: For RRC_CONNECTED UEs, if initial transmission for multicast is based on PTM transmission scheme 1, at least support retransmission(s) can use PTM transmission scheme 1.
· FFS: whether to support PTP transmission for retransmission(s).
· FFS: whether to support PTM transmission scheme 2 for retransmission(s).
· FFS: How to indicate the association between PTM scheme 1 and PTP transmitting the same TB.
· FFS: If multiple retransmission schemes are supported, then can different retransmission schemes be supported simultaneously for different UEs in the same group?
R1-2009573 Summary#3 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
R1-2009629 Summary#4 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
Decisions from GTW sessions,
Working assumption:
For multicast of RRC-CONNECTED UEs, a common frequency resource for group-common PDCCH / PDSCH is confined within the frequency resource of a dedicated unicast BWP to support simultaneous reception of unicast and multicast in the same slot
· Down select from the two options for the common frequency resource for group-common PDCCH/ PDSCH
o Option 2A: The common frequency resource is defined as an MBS specific BWP, which is associated with the dedicated unicast BWP and using the same numerology (SCS and CP)
§ FFS BWP switching is needed between the multicast reception in the MBS specific BWP and unicast reception in its associated dedicated BWP
o Option 2B: The common frequency resource is defined as an ‘MBS frequency region’ with a number of contiguous PRBs, which is configured within the dedicated unicast BWP.
§ FFS: How to indicate the starting PRB and the length of PRBs of the MBS frequency region
· FFS whether UE can be configured with no unicast reception in the common frequency resource
· FFS on details of the group-common PDCCH / PDSCH configuration
· FFS whether to support more than one common frequency resources per UE / per dedicated unicast BWP subjected to UE capabilities
Decision: As per email decision posted on Nov.11th,
Agreement: Support TDM between one unicast PDSCH and one group-common PDSCH in a slot based on UE capability for RRC_CONNECTED UEs.
Agreements: Support SPS group-common PDSCH for MBS for RRC_CONNECTED UEs
· FFS: use group-common PDCCH or UE-specific PDCCH for SPS group-common PDSCH activation/deactivation
· FFS: whether to support more than one SPS group-common PDSCH configuration per UE
· FFS: whether and how uplink feedback could be configured
· FFS: retransmission of SPS group-common PDSCH
Agreements: For PTM transmission scheme 1, the CORESET for group-common PDCCH is configured within the common frequency resource for group-common PDSCH.
· FFS: number of CORESET(s) for group-common PDCCH within the common frequency resource for group-common PDSCH
Agreement: For search space set of group-common PDCCH of PTM scheme 1 for multicast in RRC_CONNECTED state, the CCE indexes are common for different UEs in the same MBS group.
Agreements: Down select from the two options for BDs/CCEs limit for Rel-17 MBS
· Option 1: the maximum number of monitored PDCCH candidates and non-overlapped CCEs per slot per serving cell defined in Rel-15 is kept unchanged for Rel-17 MBS.
· Option 2: For UEs supporting CA capability, the budget of BDs/CCEs of an unused CC can be used for group-common PDCCH to count the number of BDs/CCEs, which is similar to the method used for multi-DCI based multi-TRP in Rel-16.
Agreement: For RRC_CONNECTED UEs, support inter-slot TDM between unicast PDSCH and group-common PDSCH in different slots (mandatory for the UE supporting MBS).
Agreements: Further study the following cases for simultaneous reception of unicast PDSCH and group-common PDSCH in a slot based on UE capability for RRC_CONNECTED UEs.
· Case 1: support TDM between multiple TDMed unicast PDSCHs and one group-common PDSCH in a slot
· Case 2: support TDM among multiple group-common PDSCHs in a slot
· Case 3: support TDM between multiple TDMed unicast PDSCHs and multiple TDMed group-common PDSCHs in a slot
· Case 4: support FDM between multiple TDMed unicast PDSCHs and multiple TDMed group-common PDSCHs in a slot
· Case 5: support FDM among multiple group-common PDSCHs in a slot
· FFS: maximum number of PDSCHs in a slot simultaneous received per UE
Agreements: For search space set of group-common PDCCH of PTM scheme 1 for multicast in RRC_CONNECTED state, further study the following options.
· Option 1: Define a new search space type specific for multicast
· Option 2: Reuse the existing CSS type(s) in Rel-15/16
o FFS: whether modifications are needed for multicast
· Option 3: Reuse the existing USS in Rel-15/16 with necessary modifications for MBS
o FFS: detailed modifications
Agreement: No specification enhancement in Rel-17 to support SDM between unicast PDSCH and group-common PDSCH in a slot for RRC_CONNECTED UEs.
R1-2009677 Summary#5 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
Decisions from GTW sessions,
Agreement: For PTM transmission scheme 1, if Option 2A or Option 2B for common frequency resource for group-common PDCCH/PDSCH is agreed, the FDRA field of group-common PDCCH is interpreted based on the common frequency resource.
Agreements: For search space set of group-common PDCCH of PTM scheme 1 for multicast in RRC_CONNECTED state, further study the following options for the monitoring priority of search space set
· Option 1: The monitoring priority of search space set for multicast is the same as existing Rel-15/16 CSS
· Option 2: The monitoring priority of search space set for multicast is the same as existing Rel-15/16 USS
· Other options are not precluded
· The monitoring priority is used at least for PDCCH overbooking case
o FFS for other cases (e.g., to prune PDCCH in terms of whether it’s unicast or multicast, etc.)
Final summary in:
R1-2009744 Summary#6 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
R1-2009275 Views on reliability enhancement for Multicast RRC_CONNECTED UEs Qualcomm Incorporated
· Proposal 1: For RRC_CONNECTED UEs, support both group NACK and UE-specific ACK/NACK for HARQ feedback and corresponding retransmission.
o FFS: PUCCH resource allocation for multicast feedback
o FFS: Type 1, 2, 3 HARQ-ACK codebook for multicast feedback
· Proposal 2: Support multiplexing of UE-specific ACK/NACK for unicast and multicast transmission based on UE capability.
o FFS: Type 1, 2, 3 HARQ-ACK codebook for multiplexing unicast and multicast feedback
· Proposal 3: For RRC_CONNECTED UEs, HARQ-ACK feedback can be optionally enabled/disabled by RRC signaling.
o The configuration of HARQ-ACK feedback can be configured for a given G-RNTI (corresponding to a service) or for a UE receiving a service.
· For GC-PDSCH repetition,
o Proposal 4: Support independent repetition configuration for GC-PDSCH with different G-RNTIs.
o Proposal 5: Support semi-static and dynamic slot-level repetition for GC-PDSCH.
§ Semi-static and dynamic repetition for GC-PDSCH are not simultaneously configured for the GC-PDSCH associated with same G-RNTI
§ FFS: gap in between repeated GC-PDSCH slots
· For CSI acquisition,
o Proposal 6: For RRC_CONNNECTED UES, configure the CSI-RS resource per Multicast BWP
§ CSI-RS bandwidth is limited within the Multicast BWP.
§ CSI-RS power is associated with GC-PDSCH power
o Proposal 7: Support GC-PDCCH to trigger A-CSI-RS transmission in Multicast BWP.
o Proposal 8: Support beam management for multicast assisted by unicast connection.
o Proposal 9: Consider SRS configuration for CSI measurement of multicast transmission in Multicast BWP.
Decision: The document is noted.
R1-2007557 Improving reliability for MC/BC services FUTUREWEI
R1-2007563 Mechanisms to improve reliablity for RRC_CONNECTED UEs Huawei, HiSilicon
R1-2007638 Study on the reliability for RRC_CONNNECTED UEs CHENGDU TD TECH LTD.
R1-2007692 Discussion on mechanisms to improve reliability for RRC_CONNECTED UEs vivo
R1-2007836 Discussion on reliability improvement mechanism for RRC_CONNECTED UEs in MBS CATT
R1-2008035 Discussion on reliability improvement CMCC
R1-2008065 Mechanisms to improve reliability of Broadcast/Multicast service LG Electronics
R1-2008193 On mechanisms to improve reliability for RRC_CONNECTED UEs Samsung
R1-2008243 UL feedback for RRC-CONNECTED UEs in MBMS OPPO
R1-2008450 Discussion on MBS reliability improvement for RRC_connected UEs Apple
R1-2008715 Reliability improvement for RRC_CONNECTED UEs in MBS Potevio
R1-2008827 Mechanisms to Improve Reliability for RRC_CONNECTED UEs ZTE
R1-2008883 Reliability Improvements for RRC_CONNECTED UEs Nokia, Nokia Shanghai Bell
R1-2008893 Views on improving reliability for RRC_CONNECTED UEs in MBS Google Inc.
R1-2008927 Discussion on reliability improvement for RRC-CONNECTED UEs Lenovo, Motorola Mobility
R1-2008962 Discussion on HARQ operation for NR MBS reliable transmission MediaTek Inc.
R1-2009001 Mechanisms to Improve Reliability for NR-MBS Intel Corporation
R1-2009166 On reliability enhancement for NR multicast and broadcast Convida Wireless
R1-2009306 Discussion on reliability mechanisms for NR MBS Ericsson
R1-2009464 FL summary on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
[103-e-NR-MBS-02] – Jinhuan (Huawei)
Email discussion/approval for mechanisms to improve reliability for RRC_CONNECTED UEs
R1-2009539 FL summary#2 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
R1-2009654 FL summary#3 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
Decisions from GTW sessions,
Agreements:
For RRC_CONNECTED UEs receiving multicast, at least for PTM scheme 1, support at least one of the following:
· ACK/NACK based HARQ-ACK feedback for multicast,
· From per UE perspective, UE feedback ACK or NACK.
· From UEs within the group perspective,
§ FFS: PUCCH resource configuration for ACK/NACK feedback e.g., shared or separate PUCCH resources.
· FFS details including conditions for it to be used
· NACK-only based HARQ-ACK feedback for multicast,
· From per UE perspective, UE only feedback NACK.
·
From UEs within the
group perspective, further down-select between:
§ FFS: PUCCH resource configuration for NACK only feedback.
· FFS details including conditions for it to be used
· To decide in RAN1#104-e whether or not to support only one or both of the above schemes
· If both are supported, FFS configuration/selection of ACK/NACK-based and NACK-only based HARQ-ACK feedback
Decision: As per email decision posted on Nov.11th,
Agreements:
For RRC_CONNECTED UEs receiving multicast, for ACK/NACK based HARQ-ACK feedback if supported for group-common PDCCH scheduling, PUCCH resource configuration for HARQ-ACK feedback from per UE perspective is, down-select one of the following options:
· Option 1: shared with PUCCH resource configuration for HARQ-ACK feedback for unicast
· Option 2: separate from PUCCH resource configuration for HARQ-ACK feedback for unicast
· Option 3: Option 1 or option 2 based on configuration
Agreements:
For RRC_CONNECTED UEs receiving multicast, for NACK-only based HARQ-ACK feedback if supported for group-common PDCCH scheduling, PUCCH resource configuration for HARQ-ACK feedback from per UE perspective is separate from PUCCH resource configuration for HARQ-ACK feedback for unicast.
· FFS PUCCH format
Agreements:
Enabling/disabling HARQ-ACK feedback for MBS is supported, further down-select between:
· Option 1: DCI
· Option 2: RRC configures enabling/disabling
· Option 3: RRC configures the enabling/ disabling function and DCI indicates enabling /disabling
· FFS: Option 4: MAC-CE indicates enabling/disabling
· FFS: Option 5: RRC configures the enabling/ disabling function and MAC-CE indicates enabling /disabling
Agreements:
For slot-level repetition for group-common PDSCH of RRC_CONNECTED UEs, for indicating the repetition number, further down-select among:
· Opt 1: by DCI
· Opt 2: by RRC
· Opt 3: by RRC+DCI
· FFS: Opt 4: by MAC-CE
· FFS: Opt 5: by RRC+MAC-CE
· FFS details for each option.
· FFS further enhancements for configuration of slot-level repetition
Agreements:
From the perspective of RRC_CONNECTED UEs receiving multicast, at least for PTM scheme 1 initial transmission, retransmission supports, for the purpose of down-selection, options are:
· Option 1: group-common PDCCH scheduled group-common PDSCH
· Option 2: UE-specific PDCCH scheduled PDSCH
o Alt 1: PDSCH is UE-specific PDSCH
o Alt 2: PDSCH is group-common PDSCH
· Option 3: both option 1 and option 2
· FFS other options
· FFS CBG based retransmission
Agreements:
FFS whether CSI feedback enhancement is needed for MBS, including but not limited:
· New CQI measurement
· New CSI report formats
· Targeted BLER
· CSI-RS configuration
· A-CSI-RS transmission triggering
· SRS configuration
Decision: As per email decision posted on Nov.13th,
Agreements:
For ACK/NACK based HARQ-ACK feedback if supported, both Type-1 and Type-2 HARQ-ACK codebook are supported for RRC_CONNECTED UEs receiving multicast,
· FFS details of HARQ-ACK codebook design.
· FFS whether enhanced Type-2 and/or Type-3 HARQ-ACK codebook is supported or not.
Final summary in:
R1-2009716 FL summary#4 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
R1-2007837 Discussion on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs CATT, CBN
· Proposal 1: It is necessary for RRC_IDLE/RRC_INACTIVE UEs to receive MBS services in NR at least for broadcast service.
· Proposal 2: The solution of the PTM configuration acquiring for MBS services (at lease for broadcast service) can be discussed based on LTE SC-PTM mechanisms.
· Proposal 3: Multi-beam operation is supported for Rel-17 MBS transmission.
· Proposal 4: For saving the frequency resource, the indications of PTP / PTM mode can be based on per-SSB.
· Proposal 5: The content of MRB in LTE can be used as a baseline for the design in Rel-17 MBS.
· Proposal 6: MO configuration for MBS services can reuse the mechanism of the paging and the SIB.
· Proposal 7: A mixed BWP can be configured to support both unicast and MBS traffic without BWP switching.
· Proposal 8: The DRX/WUS operation should be supported by the IDLE/INACTIVE UE for MBS.
Decision: The document is noted.
R1-2007564 Discussion on multicast support for IDLE/INACTIVE UEs Huawei, HiSilicon
R1-2007639 Basic functions for MBS for RRC_IDLE/RRC_INACTIVE UEs CHENGDU TD TECH LTD.
R1-2007693 Discussion on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE Ues vivo
R1-2008036 Discussion on NR MBS in RRC_IDLE/RRC_INACTIVE states CMCC
R1-2008066 Basic function for broadcast/multicast LG Electronics
R1-2008194 On basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs Samsung
R1-2008244 Discussion on enhancements for IDLE and INACTIVE state UEs OPPO
R1-2008828 Basic Functions for Broadcast or Multicast for RRC_IDLE or RRC_INACTIVE UEs ZTE
R1-2008884 Basic Functions for Broadcast / Multicast for RRC_IDLE / RRC_INACTIVE UEs Nokia, Nokia Shanghai Bell
R1-2008928 Basic functions for broadcast/multicast in idle/inactive states Lenovo, Motorola Mobility
R1-2009002 NR-MBS for RRC_IDLE/INACTIVE UEs Intel Corporation
R1-2009167 On NR multicast and broadcast for RRC_IDLE/RRC_INACTIVE UEs Convida Wireless
R1-2009276 Discussion on broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs Qualcomm Incorporated
R1-2009307 Support for NR multicast reception in RRC Inactive/Idle Ericsson
R1-2009465 Feature lead summary on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/ RRC_INACTIVE states Moderator (BBC)
[103-e-NR-MBS-03] – David (BBC)
Email discussion/approval for basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs
R1-2009553 Summary#2 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/ RRC_INACTIVE states Moderator (BBC)
R1-2009554 Summary#3 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/ RRC_INACTIVE states Moderator (BBC)
Decision from GTW session on Nov.10th,
Agreements: For RRC_IDLE/RRC_INACTIVE UEs, support group-common PDCCH with CRC scrambled by a common RNTI to schedule a group-common PDSCH, where the scrambling of the group-common PDSCH is based on the same common RNTI.
Decision: As per email decision posted on Nov.11th,
Agreements:
· For RRC_IDLE/RRC_INACTIVE Ues, beam sweeping is supported for group-common PDCCH/PDSCH.
o FFS: Details for support of beam sweeping for group-common PDCCH/PDSCH.
Decision from GTW session
Agreements: For RRC_IDLE/RRC_INACTIVE UEs, define/configure common frequency resource(s) for group-common PDCCH/PDSCH.
Agreements: From physical layer perspective, for broadcast reception, the same group-common PDCCH and the corresponding scheduled group-common PDSCH can be received by both RRC_IDLE/RRC_INACTIVE UEs and RRC_CONNECTED UEs.
Agreements: For RRC_IDLE/RRC_INACTIVE UEs, CSS is supported for group-common PDCCH.
· FFS: reuse current CSS type, define a new CSS type, etc.
· FFS other details.
Decision: As per email decision posted on Nov.13th,
Agreements: For RRC_IDLE/RRC_INACTIVE UEs, a CORESET can be configured within the common frequency resource for group-common PDCCH/PDSCH. CORESET0 is used by default if the common frequency resource for group-common PDCCH/PDSCH is the initial BWP and the CORESET is not configured.
· FFS: configuration details of the CORESET for group-common PDCCH/PDSCH
R1-2007641 Effects of NR MBS on PDSCH and PDCCH CHENGDU TD TECH LTD.
R1-2007694 Other issues for Rel-17 MBS vivo
R1-2007838 Discussion on search space type definition for group scheduling CATT
R1-2008067 Other aspects for MBS LG Electronics
R1-2008245 PUCCH resource allocation for UL feedback in MBMS OPPO
R1-2008317 Resource for receiving MBS Huawei, HiSilicon
R1-2008829 Preliminary Simulation Results of Rel-17 MBS ZTE
R1-2009308 Assumptions for Performance Evaluations of NR-MBS Ericsson
Please refer to RP-201038 for detailed scope of the WI
R1-2102197 Session notes for 8.12 (NR Multicast and Broadcast Services) Ad-Hoc Chair (Ericsson)
R1-2101062 Updated NR MBS work plan CMCC
R1-2100048 Discussion on PDCCH aspects for group scheduling FUTUREWEI
R1-2100106 Discussion on mechanisms to Support Group Scheduling for RRC_CONNECTED UEs ZTE
R1-2100144 Group scheduling for NR Multicast and Broadcast Services OPPO
R1-2100189 Resource configuration and group scheduling for RRC_CONNECTED UEs Huawei, HiSilicon
R1-2100354 Discussion on group scheduling mechanism for RRC_CONNECTED UEs in MBS CATT
R1-2100469 Discussion on mechanisms to support group scheduling for RRC_CONNECTED UEs vivo
R1-2100510 Group Scheduling Mechanisms to Support 5G Multicast / Broadcast Services for RRC_CONNECTED Ues Nokia, Nokia Shanghai Bell
R1-2100613 Discussion on NR MBS group scheduling for RRC_CONNECTED UEs MediaTek Inc.
R1-2100674 NR-MBS Group Scheduling for RRC_CONNECTED UEs Intel Corporation
R1-2100698 Views on group scheduling for NR MBS Google Inc.
R1-2100768 Discussion on group scheduling mechanism for NR MBS Lenovo, Motorola Mobility
R1-2100805 Discussion on MBS group scheduling for RRC_CONNECTED UEs Spreadtrum Communications
R1-2100872 Considerations on MBS group scheduling for RRC_CONNECTED UEs Sony
R1-2100906 Support of group scheduling for RRC_CONNECTED UEs LG Electronics
R1-2100956 Discussion on group scheduling mechanism for RRC_CONNECTED UEs ETRI
R1-2101063 Discussion on group scheduling mechanisms CMCC
R1-2101234 On mechanisms to support group scheduling for RRC_CONNECTED UEs Samsung
R1-2101359 Discussion on group scheduling mechanism for RRC_connected UEs Apple
R1-2101424 On group scheduling mechanism for NR multicast and broadcast Convida Wireless
R1-2101487 Views on group scheduling for Multicast RRC_CONNECTED UEs Qualcomm Incorporated
R1-2101579 Discussion on group scheduling for RRC_CONNECTED UEs CHENGDU TD TECH LTD.
R1-2101658 Discussion on mechanisms to support group scheduling for RRC_CONNECTED UEs ASUSTeK
R1-2101726 Mechanisms to support group scheduling for RRC_CONNECTED Ues Ericsson
[104-e-NR-MBS-01] – Fei (CMCC)
Email discussion/approval on mechanisms to support group scheduling for RRC_CONNECTED UEs with checkpoints for agreements on Jan-28, Feb-02, Feb-05
R1-2101867 Summary#3 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC) (rev of R1-2101854, rev of R1-2101767)
R1-2101875 Summary#4 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
Decision: From GTW session on Jan 28th,
Agreement:
For multicast of RRC-CONNECTED UEs, a common frequency resource for group-common PDCCH / PDSCH is confined within the frequency resource of a dedicated unicast BWP to support simultaneous reception of unicast and multicast in the same slot
· Down select from the two options for the common frequency resource for group-common PDCCH/ PDSCH
o Option 2A: The common frequency resource is defined as an MBS specific BWP, which is associated with the dedicated unicast BWP and using the same numerology (SCS and CP)
§ FFS BWP switching is needed between the multicast reception in the MBS specific BWP and unicast reception in its associated dedicated BWP
o Option 2B: The common frequency resource is defined as an ‘MBS frequency region’ with a number of contiguous PRBs, which is configured within the dedicated unicast BWP.
§ FFS: How to indicate the starting PRB and the length of PRBs of the MBS frequency region
· FFS whether UE can be configured with no unicast reception in the common frequency resource
· FFS on details of the group-common PDCCH / PDSCH configuration
· FFS whether to support more than one common frequency resources per UE / per dedicated unicast BWP subjected to UE capabilities
· FFS whether the use of a common frequency resource for multicast is optional or not
· FFS whether the common frequency resource is applicable for PTM scheme 2 (if supported) or not
Agreement:
· If Option 2B is supported for common frequency resource for multicast of RRC-CONNECTED UEs, the starting PRB and the length of PRBs of the MBS frequency region within a dedicated unicast BWP are configured via UE-specific RRC signaling.
o The starting PRB is referenced to one of the two options:
§ Option 1: Point A
§ Option 2: the starting PRB of the dedicated unicast BWP
o FFS the detailed signaling
· If Option 2A is supported for common frequency resource for multicast of RRC-CONNECTED UEs, the configurations of the starting PRB and the length of PRBs of the MBS frequency resource reuse the legacy BWP configuration.
Decision: As per email decision posted on Jan 29th,
For RRC_CONNECTED UEs, if ACK/NACK based HARQ-ACK feedback is supported for PTM scheme 1, and if initial transmission for multicast is based on PTM transmission scheme 1, support retransmission(s) using PTP transmission.
· The HARQ process ID and NDI indicated in DCI is used to associate the PTM scheme 1 and PTP transmitting the same TB.
Agreement:
The maximum number of monitored PDCCH candidates and non-overlapped CCEs per slot per serving cell defined in Rel-15 is kept unchanged for Rel-17 MBS.
· FFS whether the budget of BDs/CCEs of an unused CC can be used for group-common PDCCH to count the number of BDs/CCEs for UEs supporting CA capability based on configuration, which is similar to the method used for multi-DCI based multi-TRP in Rel-16.
Working Assumption:
Keep the “3+1” DCI size budget defined in Rel-15 for Rel-17 MBS.
· FFS: Whether the G-RNTI is counted as “C-RNTI” or as “other RNTI” when considering the “3+1” DCI size budget rule for group-common PDCCH.
Agreement:
For RRC_CONNECTED UEs, more than one SPS group-common PDSCH configuration for MBS can be configured per UE subject to UE capability
· The total number of SPS configurations supported by a UE currently defined for unicast is not increased due to additionally supporting MBS.
· FFS: How to allocate the total SPS configurations between MBS and unicast.
Agreement:
For RRC_CONNECTED UEs, support HARQ-ACK feedback for SPS group-common PDSCH for MBS
· FFS: The retransmission scheme(s)
· FFS: The HARQ-ACK details for SPS PDSCH and activation/deactivation, which can be discussed in AI 8.12.2
R1-2102032 Summary#8 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
Agreement:
From RAN1 perspective, the CFR (common frequency resource) for multicast of RRC-CONNECTED UEs, which is confined within the frequency resource of a dedicated unicast BWP and using the same numerology (SCS and CP), includes the following configurations:
Agreement:
For search space set of group-common PDCCH of PTM scheme 1 for multicast in RRC_CONNECTED state, at least support CSS
· FFS: reuse existing CSS type(s) in Rel-15/16 or define a new Type CSS
· FFS: Two options for monitoring priority:
o Option 1: the monitoring priority is the same as existing Rel-15/16 CSS
o Option 2: the monitoring priority is determined based on the search space set indexes of search space set(s) for multicast and USS sets.
R1-2102099 Summary#9 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
Decision: As per email posted on Feb 5th,
For activation/deactivation of SPS group-common PDSCH for MBS in RRC_CONNECTED state,
Final summary in R1-2102171.
R1-2100049 Discussion on improving reliability for RRC_CONNECTED UEs FUTUREWEI
R1-2100107 Discussion on mechanisms to Improve Reliability for RRC_CONNECTED UEs ZTE
R1-2100145 UL feedback for RRC-CONNECTED UEs in MBMS OPPO
R1-2100190 Mechanisms to improve reliability for RRC_CONNECTED UEs Huawei, HiSilicon
R1-2100355 Discussion on reliability improvement mechanism for RRC_CONNECTED UEs in MBS CATT
R1-2100470 Discussion on mechanisms to improve reliability for RRC_CONNECTED UEs vivo
R1-2100511 Reliability Improvements for RRC_CONNECTED UEs Nokia, Nokia Shanghai Bell
R1-2100557 Reliability improvement for RRC_CONNECTED UEs in MBS Potevio Company Limited
R1-2100614 Discussion on HARQ operation for NR MBS reliable transmission MediaTek Inc.
R1-2100675 Mechanisms to Improve Reliability of NR-MBS for RRC_CONNECTED UEs Intel Corporation
R1-2100699 Views on retransmission procedure for NR MBS Google Inc.
R1-2100769 Discussion on reliability improvement for RRC-CONNECTED UEs Lenovo, Motorola Mobility
R1-2100806 Mechanisms to improve reliability for RRC_CONNECTED UEs Spreadtrum Communications
R1-2100907 Mechanisms to improve reliability of Broadcast/Multicast service LG Electronics
R1-2100957 Discussion on mechanisms to improve reliability for RRC_CONNECTED UEs ETRI
R1-2101064 Discussion on reliability improvement CMCC
R1-2101235 On mechanisms to improve reliability for RRC_CONNECTED UEs Samsung
R1-2101360 Discussion on MBS reliability improvement for RRC_connected UEs Apple
R1-2101425 On reliability enhancement for NR multicast and broadcast Convida Wireless
R1-2101488 Views on UE feedback for Multicast RRC_CONNECTED UEs Qualcomm Incorporated
R1-2101637 Study on the reliability for RRC_CONNECTED UEs CHENGDU TD TECH LTD.
R1-2101727 Discussion on reliability mechanisms for NR MBS Ericsson
[104-e-NR-MBS-02] – Jinhuan (Huawei)
Email discussion/approval on mechanisms to improve reliability for RRC_CONNECTED UEs with checkpoints for agreements on Jan-28, Feb-02, Feb-05
R1-2101837 FL summary#1 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
R1-2101987 FL summary#3 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei) (rev of R1-2101906)
Decision: From GTW session on Feb 1st,
Agreement:
For ACK/NACK based feedback if supported for RRC_CONNECTED UEs receiving multicast, UE can be optionally configured a separate PUCCH-Config for multicast. Otherwise, PUCCH-Config for unicast applies.
Agreement:
The priority for HARQ-ACK feedback for RRC_CONNECTED UE receiving multicast can be,
· Lower, higher than or equal to the HARQ-ACK feedback for unicast
o FFS: How to reflect the priority in specification, e.g., whether it is configured or indicated to the UE
o FFS: The total number of priorities across multicast and unicast
· FFS the priority between HARQ-ACK feedback for multicast and other UCI for unicast (SR, CSI) or PUSCH for unicast.
Agreement:
For ACK/NACK based feedback if supported for multicast, for Type-2 HARQ-ACK feedback construction for PTM scheme 1,
R1-2102082 FL summary#4 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
R1-2102134 FL summary#5 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
From GTW session:
Agreement:
For RRC_CONNECTED UEs receiving multicast, support the following:
· ACK/NACK based HARQ-ACK feedback for multicast,
- It is up to network to configure orthogonal PUCCH resources among UEs within the same group.
· FFS: NACK-only based HARQ-ACK feedback for multicast,
- It is up to network to configure the PUCCH resources and the PUCCH resources can be shared among UEs within the same group.
· FFS details.
Agreement:
For the cases of HARQ-ACK feedback (at least for ACK/NACK based feedback) is available for multicast and unicast for a given UE receiving multicast, for determining the PUCCH resource,
· Support multiplexing for the same priority and prioritizing for different priorities at least when the corresponding PUCCH resources overlap in time in a slot.
o FFS whether it is subject to UE capability.
· FFS the case of non-overlapping PUCCHs resources for HARQ-ACK in the same slot.
· FFS whether sub-slot based PUCCH transmission for HARQ-ACK is supported.
· FFS the case of HARQ-ACK feedback for multicast and other UCI for unicast.
Agreement:
For ACK/NACK based feedback if supported for multicast, construction of Type-1 HARQ-ACK codebook based on the union of the PDSCH TDRA sets of the unicast service and the multicast service (if they are separately configured), at least of the same priority, is supported
· FFS details of Type-1 HARQ-ACK codebook construction for FDM-ed unicast and multicast.
· FFS details of Type-1 HARQ-ACK codebook construction for FDM-ed multicast and multicast if supported.
· FFS: whether/how to optimize the Type-1 codebook construction to reduce the HARQ-ACK feedback payload size.
Agreement:
For slot-level repetition for group-common PDSCH for RRC_CONNECTED UEs receiving multicast,
· (Config A) UE can be optionally configured with pdsch-AggregationFactor.
· (Config B) UE can be optionally configured with TDRA table with repetitionNumber as part of the TDRA table.
· If UE is configured with Config B, UE does not expect to be configured with Config A for the same group-common PDSCH.
Decision: As per email posted on Feb 5th,
For enabling/disabling HARQ-ACK feedback for RRC_CONNECTED UE receiving multicast,
· Option 3: RRC signalling configures the enabling/ disabling function of DCI indicating the enabling /disabling HARQ-ACK feedback.
• If RRC signalling configures the function, DCI indicates (explicitly or implicitly) whether HARQ-ACK feedback is enabled/disabled
- FFS details on RRC signalling and DCI indicating.
• If RRC signalling does not configure the function, DCI does not indicate enabling/disabling the HARQ-ACK feedback.
- FFS whether enabling or disabling the feedback is the default mode.
· Option 2: RRC indicates enabling/disabling.
· FFS: whether down-selection between option 3 and option 2 is needed or support the both options.
· FFS: enabling/disabling by MAC-CE.
R1-2100108 Discussion on basic Functions for Broadcast or Multicast for RRC_IDLE or RRC_INACTIVE UEs ZTE
R1-2100146 Discussion on support for IDLE and INACTIVE state UEs OPPO
R1-2100191 Discussion on multicast support for IDLE/INACTIVE UEs Huawei, HiSilicon
R1-2100356 Discussion on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs CATT, CBN
R1-2100471 Discussion on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE Ues vivo
R1-2100512 Basic Functions for Broadcast / Multicast for RRC_IDLE / RRC_INACTIVE Ues Nokia, Nokia Shanghai Bell
R1-2100615 Common frequency resource for NR PTM transmission MediaTek Inc.
R1-2100676 NR-MBS for RRC_IDLE/INACTIVE UEs Intel Corporation
R1-2100770 Basic functions for broadcast/multicast in idle/inactive states Lenovo, Motorola Mobility
R1-2100873 Considerations on MBS functions for RRC_IDLE UEs Sony
R1-2100908 Basic function for broadcast/multicast LG Electronics
R1-2101065 Discussion on NR MBS in RRC_IDLE/ RRC_INACTIVE states CMCC
R1-2101236 On basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs Samsung
R1-2101361 Discussion on MBS for RRC_IDLE/RRC_INACTIVE UEs Apple
R1-2101426 On NR multicast and broadcast for RRC_IDLE/RRC_INACTIVE UEs Convida Wireless
R1-2101489 Views on group scheduling for Multicast RRC_IDLE/INACTIVE UEs Qualcomm Incorporated
R1-2101638 Basic functions for MBS for RRC_IDLE/RRC_INACTIVE UEs CHENGDU TD TECH LTD.
R1-2101728 Support for NR multicast reception in RRC Inactive/Idle Ericsson
R1-2101721 Feature lead summary on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/ RRC_INACTIVE states Moderator (BBC)
[104-e-NR-MBS-03] – David (BBC)
Email discussion/approval on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs with checkpoints for agreements on Jan-28, Feb-02, Feb-05
R1-2101876 Feature lead summary#2 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/ RRC_INACTIVE states Moderator (BBC)
Decision: From GTW session on Jan 28th,
Agreement:
For RRC_IDLE/RRC_INACTIVE UEs, one common frequency resource for group-common PDCCH/PDSCH can be defined/configured.
· FFS: whether to define/configure more than one common frequency resources
R1-2101877 Feature lead summary#3 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/ RRC_INACTIVE states Moderator (BBC)
R1-2102067 Feature lead summary#4 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/ RRC_INACTIVE states Moderator (BBC)
R1-2102068 Feature lead summary#5 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/ RRC_INACTIVE states Moderator (BBC)
R1-2102180 Feature lead summary # 6 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/ RRC_INACTIVE states Moderator (BBC)
Agreement:
For RRC_IDLE/RRC_INACTIVE UEs, for broadcast reception, the UE may assume that group-common PDCCH/PDSCH is QCL’d with SSB.
Agreement:
For broadcast reception, the same group-common PDCCH and the corresponding scheduled group-common PDSCH can be received by both RRC_IDLE/RRC_INACTIVE UEs and RRC_CONNECTED UEs when UE-specific active BWP of RRC_CONNECTED UE contains the common frequency resource of RRC_IDLE/INACTIVE UEs and the SCS and CP are the same.
· FFS: the case when UE-specific active BWP of RRC_CONNECTED UE does not contain the common frequency resource of RRC_IDLE/INACTIVE UEs.
Agreement:
For RRC_IDLE/RRC_INACTIVE UEs, for broadcast reception, further study the following cases of a configured/defined specific common frequency resource (CFR) for group-common PDCCH/PDSCH, and identify which case(s) will be supported:
· [Case E] the case where a CFR is defined based on a configured BWP.
o In particular, study the following:
§ whether a configured BWP for MBS is needed or not.
§ whether BWP switching is needed or not.
o In this study, the configured BWP has the following properties:
§ The configured BWP is different than the initial BWP where the frequency resources of this initial BWP are configured smaller than the full carrier bandwidth.
§ The CFR has the frequency resources identical to the configured BWP.
§ The configured BWP needs to fully contain the initial BWP in frequency domain and has the same SCS and CP as the initial BWP.
o Note: The configured BWP is not larger than the carrier bandwidth
· the case where the initial BWP fully contains the CFR in the frequency domain.
o In this study the following sub-cases are considered:
o In particular, study the following:
§ Whether the considered two options with a CFR with smaller size than the initial BWP are needed or not for MBS.
· the case where the initial BWP has same size as the CFR in the frequency domain.
o In this study the following two sub-cases are considered:
§ [Case A] A CFR with the same size as the initial BWP, where the initial BWP has the same frequency resources as CORESET0. In this case the CFR has the same frequency resources and same SCS and CP as the initial BWP.
§ [Case C] A CFR with same size as the initial BWP, where the initial BWP has the frequency resources configured by SIB1. In this case the CFR has the same frequency resources and same SCS and CP as the initial BWP.
o In particular, study the following:
§ Whether the considered two options with a CFR with the same size as the initial BWP are needed or not for MBS.
R1-2100109 Consideration on performance enhancement for RRC_IDLE/INACTIVE UEs ZTE
R1-2100357 Discussion on other issues for MBS CATT
R1-2100472 Other issues for Rel-17 MBS vivo
R1-2100909 Other aspects for MBS LG Electronics
R1-2101639 Effects of NR MBS on PDSCH and PDCCH CHENGDU TD TECH LTD.
R1-2101729 Assumptions for Performance Evaluations of NR-MBS Ericsson
R1-2101730 LTE SC-PTM design as a reference for NR MBS in IDLE/INACTIVE Huawei, HiSilicon
Please refer to RP-201038 for detailed scope of the WI
R1-2103985 Session notes for 8.12 (NR Multicast and Broadcast Services) Ad-Hoc Chair (Ericsson)
R1-2102899 Updated NR MBS work plan CMCC
R1-2102909 Summary#1 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
R1-2102318 Resource configuration and group scheduling for RRC_CONNECTED UEs Huawei, HiSilicon
R1-2102414 Group scheduling for NR Multicast and Broadcast Services OPPO
R1-2102469 Discussion on MBS group scheduling for RRC_CONNECTED UEs Spreadtrum Communications
R1-2102501 Discussion on Mechanisms to Support Group Scheduling for RRC_CONNECTED UEs ZTE
R1-2102542 Discussion on mechanisms to support group scheduling for RRC_CONNECTED UEs vivo
R1-2102609 Discussion on group scheduling mechanism for RRC_CONNECTED UEs in MBS CATT
R1-2102655 Group Scheduling Mechanisms to Support 5G Multicast / Broadcast Services for RRC_CONNECTED Ues Nokia, Nokia Shanghai Bell
R1-2102702 Discussion on NR MBS group scheduling for RRC_CONNECTED UEs MediaTek Inc.
R1-2102782 Discussion on aspects for group scheduling FUTUREWEI
R1-2102844 Discussion on common frequency resource configuration for MBS ETRI
R1-2102900 Discussion on group scheduling mechanisms CMCC
R1-2103050 NR-MBS Group Scheduling for RRC_CONNECTED UEs Intel Corporation
R1-2103124 Discussion on group scheduling mechanism for RRC_CONNECTED UEs Apple
R1-2103186 Views on group scheduling for Multicast RRC_CONNECTED UEs Qualcomm Incorporated
R1-2103260 On mechanisms to support group scheduling for RRC_CONNECTED UEs Samsung
R1-2103316 Considerations on MBS group scheduling for RRC_CONNECTED UEs Sony
R1-2103357 Support of group scheduling for RRC_CONNECTED UEs LG Electronics
R1-2103362 Further discussion on group scheduling for RRC_CONNECTED UEs Chengdu TD Tech, TD Tech
R1-2103419 Discussion on group scheduling mechanism for RRC_CONNECTED UEs Convida Wireless
R1-2103546 Discussion on group scheduling mechanism for NR MBS Lenovo, Motorola Mobility
R1-2103594 Discussion on group scheduling mechanism for RRC_CONNECTED Ues NTT DOCOMO, INC.
R1-2103658 Discussion on mechanisms to support group scheduling for RRC_CONNECTED UEs ASUSTeK
R1-2103738 Mechanisms to support MBS group scheduling for RRC_CONNECTED UEs Ericsson
[104b-e-NR-MBS-01] – Fei (CMCC)
Email discussion/approval on mechanisms to support group scheduling for RRC_CONNECTED UEs with checkpoints for agreements on Apr-15, Apr-20
R1-2103831 Summary#2 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
R1-2104013 Summary#7 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
R1-2104080 Summary#9 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
Agreement:
For group-common PDCCH of Rel-17 MBS, support at least two DCI formats.
Decision: As per email decision posted on April 16th,
The same HARQ process ID and NDI are used for PTM scheme 1 (re)transmissions and PTP retransmissions of the same TB.
Agreement:
At least support the following cases for PDSCH reception for MBS in a slot based on UE capability for RRC_CONNECTED UEs
· Case 1: support TDM between M (M>1) TDMed unicast PDSCHs and one group-common PDSCH in a slot per CC
· Case 2: support TDM among N (N>1) group-common PDSCHs in a slot per CC
· Case 3: support TDM between K (K>1) TDMed unicast PDSCHs and L (L>1) TDMed group-common PDSCHs in a slot per CC
Decision: As per email decision posted on April 18th,
Agreement:
If a CFR is configured for multicast in RRC-CONNECTED state and confined within a dedicated unicast BWP, further study the following options.
· Option 1: the CORESET configured in PDCCH-config for unicast in the dedicated unicast BWP can be used for multicast transmission if the CORESET is fully contained in the CFR in frequency domain, and the CORESET configured in PDCCH-config for MBS in the CFR can be used for unicast transmission.
· Option 2: the CORESET configured in PDCCH-config for unicast in the dedicated unicast BWP cannot be used for multicast transmission even if the CORESET is fully contained in the CFR in frequency domain, and the CORESET configured in PDCCH-config for MBS in the CFR cannot be used for unicast transmission.
· Option 3: the CORESET configured in PDCCH-config for unicast in the dedicated unicast BWP can be used for multicast transmission if the CORESET is fully contained in the CFR in frequency domain, but the CORESET configured in PDCCH-config for MBS in the CFR cannot be used for unicast transmission.
· Option 4: the CORESET configured in PDCCH-config for unicast in the dedicated unicast BWP cannot be used for multicast transmission even if the CORESET is fully contained in the CFR in frequency domain, but the CORESET configured in PDCCH-config for MBS in the CFR can be used for unicast transmission.
Agreement:
One CFR is supported per dedicated unicast BWP for multicast of RRC-CONNECTED UEs.
Agreement:
The retransmission scheme for a given SPS group-common PDSCH can be either PTM scheme 1 or PTP.
Agreement:
Define G-CS-RNTI at least for SPS group-common PDSCH and activation/deactivation of SPS group-common PDSCH, different from CS-RNTI for unicast SPS PDSCH.
Conclusion:
The maximum number of HARQ processes per cell, currently supported for unicast, is kept unchanged for UE to support multicast reception.
Agreement:
Send an LS to RAN2 regarding at least the following questions:
Agreement:
Include the following in the LS to RAN2:
R1-2104045 LS on G-RNTI and G-CS-RNTI for MBS RAN1, CMCC
Decision: As per email decision posted on April 22nd, the LS is approved.
Agreement:
For CSS of group-common PDCCH of PTM scheme 1 for multicast in RRC_CONNECTED state, down-select from the following alternatives (to be decided in RAN1#105):
· Alt 1: support Type-3 CSS
o The monitoring priority of Type-3 CSS for group-common PDCCH is the same as existing Rel-15/16 CSS, regardless of which DCI format of group-common PDCCH is configured in Type-3 CSS
· Alt 2: support a new Type-x CSS
o The monitoring priority of new Type-x CSS is determined based on the search space set indexes of the new Type-x CSS set and USS sets, regardless of which DCI format of group-common PDCCH is configured in the new Type-x CSS.
· Alt 3: support both Alt 1 and Alt 2
Agreement:
The down-selection of Option 2A and Option 2B for CFR for multicast of RRC-CONNECTED UEs will be made before the end of RAN1#105-e.
Conclusion:
It is based on gNB implementation to schedule unicast on the frequency resources covered by CFR configured for multicast.
Agreement:
For RRC_CONNECTED UE supporting MBS, support up to 8 configured SPS configurations in a BWP of a serving cell for unicast and MBS in total.
Agreement:
Confirm the working assumption:
For activation/deactivation of SPS group-common PDSCH for MBS in RRC_CONNECTED state,
Final summary in R1-2104097.
R1-2102319 Mechanisms to improve reliability for RRC_CONNECTED UEs Huawei, HiSilicon
R1-2102415 UL feedback for RRC-CONNECTED UEs in MBS OPPO
R1-2102470 Mechanisms to improve reliability for RRC_CONNECTED UEs Spreadtrum Communications
R1-2102502 Discussion on Mechanisms to Improve Reliability for RRC_CONNECTED UEs ZTE
R1-2102543 Discussion on mechanisms to improve reliability for RRC_CONNECTED UEs vivo
R1-2102552 Discussion on MBS reliability for RRC_CONNECTED UEs Google Inc.
R1-2102610 Discussion on reliability improvement mechanism for RRC_CONNECTED UEs in MBS CATT, CBN
R1-2102656 Reliability Improvements for RRC_CONNECTED UEs Nokia, Nokia Shanghai Bell
R1-2102703 Discussion on mechanisms to improve reliability for RRC_CONNECTED Ues MediaTek Inc.
R1-2102783 Discussion on improving reliability for RRC_CONNECTED UEs FUTUREWEI
R1-2102845 Discussion on HARQ-ACK feedback method for MBS ETRI
R1-2102875 Reliability improvement for RRC_CONNECTED UEs in MBS Potevio Company Limited
R1-2102901 Discussion on reliability improvement CMCC
R1-2103051 Mechanisms to Improve Reliability of NR-MBS for RRC_CONNECTED UEs Intel Corporation
R1-2103125 Discussion on MBS reliability improvement for RRC_CONNECTED UEs Apple
R1-2103187 Views on UE feedback for Multicast RRC_CONNECTED UEs Qualcomm Incorporated
R1-2103261 On mechanisms to improve reliability for RRC_CONNECTED UEs Samsung
R1-2103358 Mechanisms to improve reliability of Broadcast/Multicast service LG Electronics
R1-2103363 Further discussion on reliability for RRC_CONNECTED UEs Chengdu TD TECH, TD Tech
R1-2103420 Discussion on reliability enhancement for RRC_CONNECTED UEs Convida Wireless
R1-2103547 Discussion on reliability improvement for RRC-CONNECTED UEs Lenovo, Motorola Mobility
R1-2103595 Discussion on HARQ-ACK feedback for multicast for RRC_CONNECTED Ues NTT DOCOMO, INC.
R1-2103739 Discussion on reliability mechanisms for NR MBS Ericsson
R1-2103834 FL summary#1 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
[104b-e-NR-MBS-02] – Jinhuan (Huawei)
Email discussion/approval on mechanisms to improve reliability for RRC_CONNECTED UEs with checkpoints for agreements on Apr-16, Apr-20
R1-2103900 FL summary#2 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
R1-2103929 FL summary#3 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
R1-2104031 FL summary#4 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
Agreement:
Support NACK-only based HARQ-ACK feedback for RRC_CONNECTED UEs receiving multicast.
Agreement:
Two priority indexes are introduced for multicast, with
Agreement:
For a separate PUCCH-ConfigurationList for multicast that is optionally configured, at least for ACK/NACK based HARQ-ACK feedback,
For Type-2 HARQ-ACK codebook concatenation to be multiplexed in the same PUCCH resource,
Agreement:
For multiplexing the ACK/NACK-based HARQ-ACK feedback for multicast and unicast, determining the PUCCH resources for transmission is based on the PRI indicated in the “last DCI”, where the “last DCI” refers to, down-select the following alternatives:
· Alt.1: the last DCI for unicast;
· Alt.2: the last DCI across unicast and multicast;
Final summary in R1-2104098.
Void (not be handled during this e-meeting). No contributions please.
The following is not treated/withdrawn.
R1-2102553 Discussion on MBS for RRC_IDLE/INACTIVE UE Google Inc.
Void (not be handled during this e-meeting). No contributions please.
The following is not treated/withdrawn.
R1-2103364 MBS related network planning for delivery mode 1 Chengdu TD Tech, TD Tech
Please refer to RP-201038 for detailed scope of the WI
R1-2106235 Session notes for 8.12 (NR Multicast and Broadcast Services) Ad-Hoc Chair (Ericsson)
R1-2104195 Group Scheduling Aspects for Connected UEs FUTUREWEI
R1-2104248 Resource configuration and group scheduling for RRC_CONNECTED UEs Huawei, HiSilicon, CBN
R1-2104336 Discussion on Mechanisms to Support Group Scheduling for RRC_CONNECTED UEs ZTE
R1-2104387 Discussion on mechanisms to support group scheduling for RRC_CONNECTED UEs vivo
R1-2104442 Discussion on MBS group scheduling for RRC_CONNECTED UEs Spreadtrum Communications
R1-2104491 Discussion on group scheduling mechanism for RRC_CONNECTED UEs in MBS CATT
R1-2104550 Group Scheduling Mechanisms to Support 5G Multicast / Broadcast Services for RRC_CONNECTED Ues Nokia, Nokia Shanghai Bell
R1-2104632 Discussion on group scheduling mechanisms CMCC
R1-2104695 Views on group scheduling for Multicast RRC_CONNECTED UEs Qualcomm Incorporated
R1-2104759 Group scheduling for NR Multicast and Broadcast Services OPPO
R1-2104865 On group scheduling mechanism for NR MBS Lenovo, Motorola Mobility
R1-2104928 NR-MBS Group Scheduling for RRC_CONNECTED UEs Intel Corporation
R1-2105069 Discussion on Group Scheduling and Simultaneous MBS and Unicast Reception TCL Communication Ltd.
R1-2105128 Discussion on group scheduling mechanism for RRC_CONNECTED UEs Apple
R1-2105179 Considerations on MBS group scheduling for RRC_CONNECTED UEs Sony
R1-2105336 Support of group scheduling for RRC_CONNECTED Ues Samsung
R1-2105381 Discussion on NR MBS group scheduling for RRC_CONNECTED UEs MediaTek Inc.
R1-2105437 Support of group scheduling for RRC_CONNECTED UEs LG Electronics
R1-2105600 Discussion on group scheduling mechanism for RRC_CONNECTED UEs Convida Wireless
R1-2105647 Discussion on common frequency resource for multicast of RRC_CONNECTED UEs ETRI
R1-2105670 Discussion on group scheduling mechanism for RRC_CONNECTED UEs Google Inc.
R1-2105720 Discussion on group scheduling mechanism for RRC_CONNECTED UEs NTT DOCOMO, INC.
R1-2105838 Discussion on group scheduling for RRC_CONNECTED UEs CHENGDU TD TECH LTD.
R1-2105844 Discussion on mechanisms to support group scheduling for RRC_CONNECTED UEs ASUSTeK
R1-2105914 Mechanisms to support MBS group scheduling for RRC_CONNECTED Ues Ericsson
[105-e-NR-MBS-01] – Fei (CMCC)
Email discussion/approval on mechanisms to support group scheduling for RRC_CONNECTED UEs with checkpoints for agreements on May 24, May 27
R1-2105973 Summary#1 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
From GTW session:
Agreement:
For CSS of group-common PDCCH of PTM scheme 1 for multicast in RRC_CONNECTED state, Alt 2 is supported:
· Alt 2: support a Type-x CSS
o The monitoring priority of Type-x CSS is determined based on the search space set indexes of the Type-x CSS set and USS sets, regardless of which DCI format of group-common PDCCH is configured in the Type-x CSS.
· FFS: Whether the Type-x CSS is a Type-3 CSS
R1-2106093 Summary#3 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
From GTW session:
Agreement:
For PTP retransmission of SPS group-common PDSCH, CS-RNTI is used for CRC scrambling of PDCCH with the NDI bit set to 1.
Agreement:
As a baseline, reuse existing fields in DCI format 1_0 with CRC scrambled by C-RNTI for the fields of first DCI format with CRC scrambled with G-RNTI.
· FFS: how to determine the bitlength of FDRA field.
· FFS: Whether ‘Identifier for DCI formats’, ‘TPC command for scheduled PUCCH’ are needed.
· FFS: How to perform DCI size alignment
· FFS: Whether to include new DCI fields
· Note: All of the fields may not be reused and the size of the fields may not be the same
Working assumption:
Option 2B for CFR associated with UE active BWP other than initial BWP is supported at least for multicast of RRC-CONNECTED UEs.
R1-2106169 Summary#5 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
Decision: As per email decision posted on May 25th,
For multicast of RRC_CONNECTED UEs, further study
Agreement:
Confirm the working assumption:
Keep the “3+1” DCI size budget defined in Rel-15 for Rel-17 MBS.
Agreement:
For Rel-17 MBS UE, the UE maximum number of TDMed PDSCH receptions capability in a slot per CC is kept as for Rel-15/Rel-16, i.e., {2/4/7} based on UE FG5-11/5-11a/5-11b.
From GTW session:
Agreement:
For reliability of the group-common PDCCH activation of SPS group-common PDSCH, support at least one of the following alternatives.
· Alt 1: retransmit the activation command via group-common PDCCH.
· Alt 2: retransmit the activation command via UE-specific PDCCH.
· Alt 3: retransmit the activation command via MAC-CE.
· FFS other details.
· Note: Down-selection can take into account the HARQ-ACK feedback scheme for SPS activation
Working assumption:
The maximum number of CORESETs per BWP is not increased for support of MBS, and the number of CORESETs configured within the CFR is left to gNB implementation.
Agreement:
As a baseline, reuse existing fields in DCI format 1_1 for the fields of the second DCI format with CRC scrambled with G-RNTI.
· FFS: whether ‘Identifier for DCI formats’, ‘TPC command for scheduled PUCCH’, ‘Carrier indicator’ and ‘Bandwidth part indicator’ are needed.
· FFS: How to perform DCI size alignment
· FFS: Whether to include new DCI fields for the second DCI format
· Note: All of the fields may not be reused and the size of the fields may not be the same
Agreement:
For HARQ process management, further study whether/how to differentiate the HARQ process ID used for PTP (re)transmission for unicast and PTP retransmission for multicast.
Final summary in R1-2106304.
R1-2104196 Further Discussions on Reliability for RRC_CONNECTED UEs FUTUREWEI
R1-2104249 Mechanisms to improve reliability for RRC_CONNECTED UEs Huawei, HiSilicon
R1-2104337 Discussion on Mechanisms to Improve Reliability for RRC_CONNECTED UEs ZTE
R1-2104388 Discussion on mechanisms to improve reliability for RRC_CONNECTED UEs vivo
R1-2104443 Mechanisms to improve MBS reliability for RRC_CONNECTED UEs Spreadtrum Communications
R1-2104492 Discussion on reliability improvement mechanism for RRC_CONNECTED UEs in MBS CATT, CBN
R1-2104551 Reliability Improvements for RRC_CONNECTED UEs Nokia, Nokia Shanghai Bell
R1-2104633 Discussion on reliability improvement CMCC
R1-2104696 Views on UE feedback for Multicast RRC_CONNECTED UEs Qualcomm Incorporated
R1-2104760 UL feedback for RRC-CONNECTED UEs in MBS OPPO
R1-2104866 On reliability improvement for RRC-CONNECTED UEs Lenovo, Motorola Mobility
R1-2104929 Mechanisms to Improve Reliability of NR-MBS for RRC_CONNECTED UEs Intel Corporation
R1-2105129 Discussion on MBS reliability improvement for RRC_CONNECTED UEs Apple
R1-2105337 On mechanisms to improve reliability for RRC_CONNECTED UEs Samsung
R1-2105382 Discussion on mechanisms to improve reliability for RRC_CONNECTED UEs MediaTek Inc.
R1-2105438 Mechanisms to improve reliability of Broadcast/Multicast service LG Electronics
R1-2105601 Discussion on reliability enhancement for RRC_CONNECTED UEs Convida Wireless
R1-2105648 Discussion on HARQ-ACK feedback for multicast of RRC_CONNECTED UEs ETRI
R1-2105721 Discussion on HARQ-ACK feedback for multicast for RRC_CONNECTED UEs NTT DOCOMO, INC.
R1-2105843 Discussion on reliability for RRC_CONNECTED UEs CHENGDU TD TECH LTD.
R1-2105915 Mechanisms to improve reliability for RRC_CONNECTED Ues Ericsson
[105-e-NR-MBS-02] – Jinhuan (Huawei)
Email discussion/approval on mechanisms to improve reliability for RRC_CONNECTED UEs with checkpoints for agreements on May 25, May 27
R1-2106012 FL summary#1 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
From GTW session:
Agreement:
The signalling for URLLC feature can be reused to configure separate codebooks for unicast and multicast, respectively, at least for the case of different priorities, at least for Type-2 HARQ codebook
· FFS: The case for the same priority.
· FFS: The case of Type-1 HARQ codebook
· FFS: Whether this applies to separate PUCCH transmissions only
R1-2106064 FL summary#2 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
From GTW session:
Agreement:
Support PUCCH format 0 and format 1 for NACK-only based HARQ-ACK feedback for multicast.
Agreement:
Support NACK-only based HARQ-ACK feedback at least for multicast SPS PDSCH without PDCCH scheduling.
· FFS for SPS activation/deactivation.
Agreement:
The priority of multicast is the same as the priority of unicast for the same priority index of HARQ-ACK at least for ACK/NACK based feedback.
R1-2106113 FL summary#3 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
From GTW session:
Agreement:
NR supports at least the following cases for UE supporting multicast:
· UE supports two non-overlapping slot-based PUCCHs for ACK/NACK based HARQ-ACK feedback for multicast with different priorities in a slot subject to UE capability.
· UE supports two non-overlapping slot-based PUCCHs for ACK/NACK based HARQ-ACK feedback for multicast and unicast with different priorities, respectively, in a slot subject to UE capability.
Agreement:
For Type-1 HARQ-ACK codebook construction for FDM-ed unicast and multicast with the same priority from the same TRP, support
· Opt 4: HARQ-ACK bits for all the PDSCH occasions over all the slots for all serving cells for unicast, precede, HARQ-ACK bits for all the PDSCH occasions over all the slots for all serving cells for multicast. (This is similar to the joint Type-1 codebook for mTRP).
· FFS: If UE reports the capability of supporting the FDM-ed unicast and multicast in the same slot, UE can be indicated semi-statically to generate Type-1 HARQ-ACK codebook as FDM-ed manner (i.e., Opt 4).
o Otherwise, UE does not expect unicast and multicast are to be scheduled in FDM-ed.
Conclusion:
PUCCH resource for NACK-only can be shared by UEs transmitting the NACK-only based HARQ-ACK feedback.
Agreement:
For ACK/NACK based HARQ-ACK feedback for multicast, the multiplexing/prioritizing rule between the HARQ-ACK for multicast and SR/CSI can reuse Rel-16 multiplexing/ prioritizing rule between the HARQ-ACK for unicast and SR/CSI.
Agreement:
For support of ACK/NACK based HARQ-ACK feedback for SPS multicast,
· the HARQ-ACK codebook index corresponding the HARQ-ACK codebook for SPS PDSCH is included in the configuration for SPS multicast.
o UE determines a priority index from the HARQ-ACK codebook index
· UE can be optionally configured a separate SPS-PUCCH-AN-List for all SPS multicast configurations. Otherwise, a common SPS-PUCCH-AN-List applies to all SPS unicast and SPS multicast configurations.
R1-2106324 FL summary#5 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
From GTW session:
Agreement:
For TDM-ed unicast and multicast, for Type-1 HARQ-ACK codebook construction for ACK/NACK-based unicast and multicast to be multiplexed in the same PUCCH resource, determining PDSCH reception candidate occasions is based on down-selecting one of the two alternatives as follows:
· Alt 1:
o
for slot timing values 
in the intersection of set for unicast (termed
set A) and set for multicast (termed set B), based on union of the PDSCH
TDRA sets,
o
for slot timing values in set A but not in set B, based on PDSCH TDRA set for unicast, and
o
for slot timing values in set B but not in set A, based on PDSCH TDRA set for multicast.
·
Alt 2: for slot timing
values in the union of set for unicast and 
set for multicast, based on the union of the PDSCH TDRA sets.
· Companies are encouraged to continue discussion of pros and cons for each alternative for further down-selection in the next meeting.
Decision: As per email decision posted on May 27th,
assumption:
For enabling/disabling ACK/NACK-based HARQ-ACK feedback for RRC_CONNECTED UE receiving multicast via dynamic group-common PDSCH:
Final summary in R1-2106330.
R1-2104197 MBS Support for RRC IDLE/INACTIVE UEs FUTUREWEI
R1-2104250 Discussion on UE receiving broadcast in RRC IDLE/INACTIVE state Huawei, HiSilicon, CBN
R1-2104338 Discussion on basic Functions for Broadcast or Multicast for RRC_IDLE or RRC_INACTIVE UEs ZTE
R1-2104389 Discussion on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs vivo
R1-2104444 Basic Functions for Broadcast or Multicast for RRC_IDLE or RRC_INACTIVE UEs Spreadtrum Communications
R1-2104493 Discussion on basic functions for MBS for RRC_IDLEINACTIVE UEs CATT, CBN
R1-2104552 Basic Functions for Broadcast / Multicast for RRC_IDLE / RRC_INACTIVE Ues Nokia, Nokia Shanghai Bell
R1-2104634 Discussion on NR MBS in RRC_IDLE/ RRC_INACTIVE states CMCC
R1-2104697 Views on group scheduling for Multicast RRC_IDLE/INACTIVE UEs Qualcomm Incorporated
R1-2104761 Discussion on support for IDLE and INACTIVE state Ues OPPO
R1-2104867 Basic functions for broadcast/multicast in idle/inactive states Lenovo, Motorola Mobility
R1-2104930 NR-MBS for RRC_IDLE/INACTIVE UEs Intel Corporation
R1-2105130 Discussion on MBS for RRC_IDLE/RRC_INACTIVE UEs Apple
R1-2105180 Considerations on MBS functions for RRC_IDLE/RRC_INACTIVE UEs Sony
R1-2105338 On basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs Samsung
R1-2105383 Discussion on broadcast or multicast for RRC_IDLE or INACTIVE UEs MediaTek Inc.
R1-2105439 Basic function for broadcast/multicast LG Electronics
R1-2105602 Discussion on MBS for RRC_IDLE/RRC_INACTIVE UEs Convida Wireless
R1-2105673 Discussion on MBS for RRC_IDLE/INACTIVE UE Google Inc.
R1-2105722 Discussion on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs NTT DOCOMO, INC.
R1-2105849 Basic functions for MBS for RRC_IDLE/RRC_INACTIVE UEs CHENGDU TD TECH LTD.
R1-2105916 Support for NR multicast reception in RRC Inactive/Idle Ericsson
R1-2105993 Feature Lead summary #1 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/RRC_INACTIVE states Moderator (BBC)
[105-e-NR-MBS-03] – David (BBC)
Email discussion/approval on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs with checkpoints for agreements on May 24, May 27
R1-2105994 Feature lead summary #2 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/ RRC_INACTIVE states Moderator (BBC)
From GTW session:
Agreement:
For RRC_IDLE/RRC_INACTIVE UEs, for broadcast reception, both searchSpace#0 and common search space other than searchSpace#0 can be configured for GC-PDCCH scheduling MCCH.
R1-2105995 Feature lead summary #3 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/ RRC_INACTIVE states Moderator (BBC)
From GTW session:
Agreement:
For RRC_IDLE/RRC_INACTIVE UEs, for broadcast reception, DCI format 1_0 is used as baseline for GC-PDCCH of MCCH and MTCH.
Agreement:
For RRC_IDLE/RRC_INACTIVE UEs, for broadcast reception, RAN1 confirms the following assumptions made by RAN2
Agreement:
For broadcast reception, RRC_IDLE/RRC_INACTIVE UEs support the same CSS type for MCCH and MTCH.
Agreement:
For RRC_IDLE/RRC_INACTIVE UEs, for broadcast reception, study the following alternatives for MCCH change notification indication due to session start:
Other solutions are not precluded and it is also not precluded whether to support both Alt1 and Alt2.
Conclusion:
It is up to RAN2 to decide the specific contents of the MCCH change notification, e.g, whether notification only informs about session start, whether or not notification also informs about session modification/stop or whether or not the notification informs about any other information.
R1-2106217 Feature Lead summary #4 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/ RRC_INACTIVE states Moderator (BBC)
From GTW session:
Agreement:
For broadcast reception, RRC_IDLE/RRC_INACTIVE UEs can use a configured/defined CFR with the same size as the initial BWP, where the initial BWP has the same frequency resources as CORESET0 (i.e., Case A), to receive GC-PDCCH/PDSCH carrying MCCH.
· Note: GC-PDCCH/PDSCH transmission within a narrower portion of the Initial BWP (where the initial BWP has the same frequency resources as CORESET0) is possible by implementation via appropriate scheduling.
Agreement:
For broadcast reception, RRC_IDLE/RRC_INACTIVE UEs can use a configured/defined CFR with the same size as the initial BWP, where the initial BWP has the same frequency resources as CORESET0 (i.e., Case A), to receive GC-PDCCH/PDSCH carrying MTCH.
Agreement:
For RRC_IDLE/RRC_INACTIVE UEs, the CORESET index can be the same for GC-PDCCH of MCCH and MTCH.
Agreement:
For RRC_IDLE/RRC_INACTIVE UEs, for broadcast reception, the same beam can be used for group-common PDCCH and the corresponding scheduled group-common PDSCH for carrying MCCH or MTCH.
Agreement:
For Rel-17, for broadcast reception, RRC_IDLE/RRC_INACTIVE UEs do not exceed the maximum number of CORESETs mandatorily (in the minimum capability) supported for Rel-15/Rel-16 UEs, i.e., 2 CORESETs.
· If the CFR has the same frequency range as the initial BWP, where the initial BWP has the same frequency resources as CORESET0 or where the initial BWP has the frequency resources configured by SIB1, RRC_IDLE/RRC_INACTIVE UEs can be configured with the following options:
o CORESET#0 (default option if CFR is the initial BWP and CORESET is not configured); or
o CORESET configured by commonControlResourceSet; or
o CORESET#0 and CORESET configured by commonControlResourceSet.
Final summary in R1-2106218.
R1-2104339 Consideration on performance enhancement for RRC_IDLE/INACTIVE UEs ZTE
R1-2104390 Other issues for Rel-17 MBS vivo
R1-2104494 Discussion on other issues in Rel-17 MBS CATT
R1-2104762 PUCCH resource allocation for NACK-only based HARQ-ACK feedback in MBMS OPPO
R1-2105440 Other aspects for MBS LG Electronics
R1-2105526 Impact from MCCH and MTCH on broadcast reception Huawei, HiSilicon
R1-2105855 MBS related network planning for two delivery modes CHENGDU TD TECH LTD.
R1-2105917 Assumptions for performance evaluations of NR-MBS Ericsson
Please refer to RP-201038 for detailed scope of the WI
R1-2108610 Session notes for 8.12 (NR Multicast and Broadcast Services) Ad-Hoc Chair (Ericsson)
R1-2106438 Resource configuration and group scheduling for RRC_CONNECTED UEs Huawei, HiSilicon, CBN
R1-2106623 Discussion on mechanisms to support group scheduling for RRC_CONNECTED Ues vivo
R1-2106662 Group Scheduling Mechanisms to Support 5G Multicast / Broadcast Services for RRC_CONNECTED Ues Nokia, Nokia Shanghai Bell
R1-2106716 Discussion on MBS group scheduling for RRC_CONNECTED UEs Spreadtrum Communications
R1-2106745 Discussion on Mechanisms to Support Group Scheduling for RRC_CONNECTED UEs ZTE
R1-2106820 Considerations on MBS group scheduling for RRC_CONNECTED UEs Sony
R1-2106912 Support of group scheduling for RRC_CONNECTED Ues Samsung
R1-2106945 Discussion on group scheduling mechanism for RRC_CONNECTED UEs in MBS CATT
R1-2106996 Common frequency resource configuration for multicast of RRC_CONNECTED Ues ETRI
R1-2107093 Group Scheduling Aspects for Connected UEs FUTUREWEI
R1-2107137 Discussion on Group Scheduling Mechanisms for RRC_CONNECTED Ues NEC
R1-2107160 On group scheduling mechanism for NR MBS Lenovo, Motorola Mobility
R1-2107201 Discussion on group scheduling mechanisms for RRC_CONNECTED UEs Potevio Company Limited
R1-2107229 Discussion on group Scheduling mechanism for RRC_CONNECTED UEs OPPO
R1-2107369 Views on group scheduling for Multicast RRC_CONNECTED UEs Qualcomm Incorporated
R1-2107382 Discussion on group scheduling mechanism for RRC_CONNECTED UEs Google Inc.
R1-2107425 Discussion on group scheduling mechanisms CMCC
R1-2107456 Support of group scheduling for RRC_CONNECTED UEs LG Electronics
R1-2107514 Discussion on NR MBS group scheduling for RRC_CONNECTED UEs MediaTek Inc.
R1-2107611 NR-MBS Group Scheduling for RRC_CONNECTED UEs Intel Corporation
R1-2107763 Discussion on group scheduling mechanism for RRC_CONNECTED Ues Apple
R1-2107881 Discussion on group scheduling mechanism for RRC_CONNECTED UEs NTT DOCOMO, INC.
R1-2107902 Discussion on mechanisms to support group scheduling for RRC_CONNECTED UE Xiaomi
R1-2107950 Group scheduling related discussion for RRC_CONNECTED UEs CHENGDU TD TECH LTD.
R1-2108026 Discussion on group scheduling mechanism for RRC_CONNECTED UEs Convida Wireless
R1-2108046 Discussion on mechanisms to support group scheduling for RRC_CONNECTED UEs ASUSTeK
R1-2108170 Mechanisms to support MBS group scheduling for RRC_CONNECTED Ues Ericsson
[106-e-NR-MBS-01] – Fei (CMCC)
Email discussion/approval on mechanisms to support group scheduling for RRC_CONNECTED UEs with checkpoints for agreements on August 19, 24 and 27
R1-2108308 Summary#2 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC) (rev of R1-2107424)
From GTW session:
Agreement:
Confirm the working assumption with the following update:
Option 2B for CFR associated with UE active BWP other than initial DL BWP is supported at least for multicast of RRC-CONNECTED UEs.
·
FFS: CFR associated
with initial BWP
·
FFS: CFR larger than
initial BWP
Note: The deleted FFSs can be discussed in another AI.
R1-2108368 Summary#4 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC) (rev of R1-2108359)
From GTW session:
Agreement:
For multicast of RRC-CONNECTED UEs, align the size of the first DCI format for GC-PDCCH with DCI format 1_0 with CRC scrambled by C-RNTI monitored in CSS.
Agreement:
Confirm the following working assumption:
The maximum number of CORESETs per BWP is not increased for support of MBS, and the number of CORESETs configured within the CFR is left to gNB implementation.
Agreement:
For indication of the starting PRB and the length of PRBs of CFR for multicast of RRC-CONNECTED UEs,
Agreement:
For LBRM and TBS determination for GC-PDSCH:
o FFS the default value.
o FFS: if mcs-Table in PDSCH-Config for MBS is not configured in CFR, a value determined from mcs-Table in PDSCH-Config for unicast in the active DL BWP is used; if the mcs-Table in PDSCH-Config for unicast is not configured, Table 5.1.3.1-1 in TS38.214 is used (similar as the default value in R16).
Agreement:
The first DCI format for GC-PDCCH uses the same fields as DCI format 1_0 with CRC scrambled by C-RNTI with the following modifications:
· At least ‘Identifier for DCI formats’ is not needed.
o FFS: Whether the field should be ignored and reserved, or should be removed.
· For FDRA determination, down-select from following options:
o Option 1:
§
is
given by
· the size of CORESET 0 if CORESET 0 is configured for the cell; and
· the size of initial DL bandwidth part if CORESET 0 is not configured for the cell.
§ For resource indication value (RIV) of downlink resource allocation type 1, the resource blocks that can be indicated are
· the resource blocks in the CORESET 0 if CORESET 0 is configured for the cell; and
· the resource blocks in the initial DL bandwidth part if CORESET 0 is not configured for the cell.
o Option 2:
§
is
given by
· the size of CORESET 0 if CORESET 0 is configured for the cell; and
· the size of initial DL bandwidth part if CORESET 0 is not configured for the cell.
§ For resource indication value (RIV) of downlink resource allocation type 1, the similar scheme as for the case that the DCI size for DCI format 1_0 in USS is derived from the size of DCI format 1_0 in CSS but applied to an active BWP is used.
·
FFS details, e.g., if the
size of CFR (i.e. 
) is larger than the size of CORESET0/initial DL bandwidth part, the
resource indication value (RIV) is defined as
in section 5.1.2.2.2 in TS38.214, where K is the maximum value from set
{1, 2, 4, 8} which satisfies 
;otherwise, 
o
Option 3: is
given by the size of CFR in the active DL BWP
Agreement:
The second DCI format for GC-PDCCH uses the same fields as DCI format 1_1 with the following modifications:
· At least ‘Identifier for DCI formats’ and ‘SRS request’ are not needed.
o FFS whether the fields should be ignored and reserved, or should be removed.
· Note: At least the configurable fields in DCI format 1_1 remain configurable for the second DCI format
R1-2108471 Summary#6 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC) (rev of R1-2108459)
From GTW session:
Agreement:
For initializing scrambling sequence generator for GC-PDCCH with the second DCI format,
·
equals the higher layer parameter pdcch-DMRS-ScramblingID if
it is configured in the CORESET in a CFR used for the GC-PDCCH; 
otherwise.
·
FFS: Values for 
. Choices include one or more of the following:
o Alt1: G-RNTI used for the GC-PDCCH.
o Alt2: 0
o Alt3: Other fixed values
Agreement:
If a SPS-config for MBS is configured in CFR, one G-CS-RNTI is associated with the SPS-config.
Agreement:
For FDRA determination of the first DCI format for GC-PDCCH, down-select from Option 2 and updated Option 3.
o Option 2:
§
is
given by
· the size of CORESET 0 if CORESET 0 is configured for the cell; and
· the size of initial DL bandwidth part if CORESET 0 is not configured for the cell.
§ For resource indication value (RIV) of downlink resource allocation type 1, the similar scheme as for the case that the DCI size for DCI format 1_0 in USS is derived from the size of DCI format 1_0 in CSS but applied to an active BWP is used.
·
FFS details, e.g., if the
size of CFR (i.e. 
) is larger than the size of CORESET0/initial DL bandwidth part, the
resource indication value (RIV) is defined as
in section 5.1.2.2.2 in TS38.214, where K is the maximum value from set
{1, 2, 4, 8} which satisfies ;otherwise,
o
Option 3: is
given by the size of CFR in the active DL BWP
§ If the size of the first DCI format for GC-PDCCH prior to truncation is larger than the size of DCI format 1_0 monitored in CSS, the bit width of the FDRA field in the first DCI format for GC-PDCCH is reduced by truncating the first few most significant bits such that the size of the first DCI format for GC-PDCCH equals the size of DCI format 1_0 monitored in CSS.
§ FFS: Whether the removed/reserved fields can be repurposed for FDRA
§ FFS: Solution for the case where the size of the first DCI format for GC-PDCCH prior to padding is smaller than the size of DCI format 1_0 monitored in CSS.
R1-2108574 Summary#8 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC) (rev of R1-2108549)
From GTW session:
Conclusion:
The specification impact of having a new Type-x CSS for GC-PDCCH in RRC_CONNECTED state can be studied and discussed further.
Agreement:
For initializing scrambling sequence generator for GC-PDSCH scheduled by the second DCI format for multicast received in Type-x CSS,
·
equals the higher layer parameter dataScramblingIdentityPDSCH if it is
configured in PDSCH-Config in a CFR used for GC-PDSCH and the RNTI equals the G-RNTI or G-CS-RNTI; otherwise.
·
corresponds to the RNTI associated with the GC-PDSCH transmission (i.e., the G-RNTI
used by the scheduling GC-PDCCH, or the G-CS-RNTI used by the SPS GC-PDSCH
activation PDCCH)
Agreement:
For initializing sequence generator for DMRS of GC-PDCCH with the second DCI format received in Type-x CSS,
equals the higher layer parameter pdcch-DMRS-ScramblingID if it is configured in the CORESET in a CFR used for the
GC-PDCCH; 
otherwise. R1-2106439 Mechanisms to improve reliability for RRC_CONNECTED UEs Huawei, HiSilicon, CBN
R1-2106624 Discussion on mechanisms to improve reliability for RRC_CONNECTED Ues vivo
R1-2106663 Reliability Improvements for RRC_CONNECTED UEs Nokia, Nokia Shanghai Bell
R1-2106717 Mechanisms to improve MBS reliability for RRC_CONNECTED Ues Spreadtrum Communications
R1-2106746 Discussion on Mechanisms to Improve Reliability for RRC_CONNECTED UEs ZTE
R1-2106913 On mechanisms to improve reliability for RRC_CONNECTED UEs Samsung
R1-2106946 Discussion on reliability improvement mechanism for RRC_CONNECTED UEs in MBS CATT, CBN
R1-2106997 HARQ-ACK feedback scheme for multicast of RRC_CONNECTED Ues ETRI
R1-2107094 Further Discussions on Reliability for RRC_CONNECTED UEs FUTUREWEI
R1-2107138 Discussion on Reliability Improvements for RRC_CONNECTED UEs NEC
R1-2107161 On reliability improvement for RRC-CONNECTED UEs Lenovo, Motorola Mobility
R1-2107230 UL feedback for RRC-CONNECTED UEs in MBS OPPO
R1-2107370 Views on UE feedback for Multicast RRC_CONNECTED UEs Qualcomm Incorporated
R1-2107383 Discussion on MBS reliability for RRC_CONNECTED UEs Google Inc.
R1-2107426 Discussion on reliability improvement CMCC
R1-2107457 Mechanisms to improve reliability of Broadcast/Multicast service LG Electronics
R1-2107515 Discussion on mechanisms to improve reliability for RRC_CONNECTED UEs MediaTek Inc.
R1-2107612 Mechanisms to Improve Reliability of NR-MBS for RRC_CONNECTED UEs Intel Corporation
R1-2107764 Discussion on MBS reliability improvement for RRC_CONNECTED UEs Apple
R1-2107882 Discussion on mechanisms to improve reliability for multicast for RRC_CONNECTED UEs NTT DOCOMO, INC.
R1-2107951 Reliability related discussion for RRC_CONNECTED UEs CHENGDU TD TECH LTD.
R1-2108027 Discussion on reliability enhancement for RRC_CONNECTED UEs Convida Wireless
R1-2108171 Mechanisms to improve reliability for RRC_CONNECTED Ues Ericsson
[106-e-NR-MBS-02] – Jinhuan (Huawei)
Email discussion/approval on mechanisms to improve reliability for RRC_CONNECTED UEs with checkpoints for agreements on August 19, 24 and 27
R1-2108332 FL summary#2 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei) (rev of R1-2108285)
Agreement:
For UE supporting both unicast and multicast, the pdsch-HARQ-ACK-Codebook/pdsch-HARQ-ACK-CodebookList can be separately configured for multicast from that for unicast.
Agreement:
When UE is configured Type-1 codebooks for unicast and multicast with different priorities, respectively, the UE separately generates each of the Type-1 codebooks.
· FFS: How UE is configured one codebook for unicast and one codebook for multicast and the two codebooks are of different priorities.
Decision: As per email decision posted on Aug 20th,
For a UE configured with Type-1 HARQ-ACK codebook,
R1-2108372 FL summary#3 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
R1-2108429 FL summary#4 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
R1-2108481 FL summary#5 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
From GTW session:
Agreement:
For UEs supporting ACK/NACK-based HARQ-ACK feedback for multicast and unicast, the following values are unchanged compared to unicast in Rel-16:
· The maximum number of PUCCH resources sets in each PUCCH-Config,
· The maximum number of PUCCH resources in a PUCCH resource set in each PUCCH-Config,
· The maximum number of UCI information bits for the first PUCCH resource set.
· The total number of PUCCH resources from all PUCCH-Config/PUCCH-ConfigurationList.
· Note:
o This applies to both cases of whether or not UE is configured optionally with a separate PUCCH-Config or PUCCH-ConfigurationList for multicast.
o The case of NACK-only based is discussed separately.
Agreement:
When UE is configured with the pdsch-HARQ-ACK-Codebook/pdsch-HARQ-ACK-CodebookList for ACK/NACK based feedback for multicast, it is applied to all G-RNTIs configured to UE.
Agreement:
For the separate PUCCH-ConfigurationList that is optionally configured to UE for NACK-only based HARQ-ACK feedback for multicast,
· The separate PUCCH-ConfigurationList for multicast configuration can be a list which includes up to 2 PUCCH-Config configurations corresponding low priority feedback and high priority feedback, respectively.
· FFS: how to handle the case when separate PUCCH-ConfigurationList is not configured to UE for NACK-only based HARQ-ACK feedback for multicast.
Agreement:
The priority index is,
· for the second DCI format for GC-PDCCH, optionally configured to be included in the DCI format. If not configured, the priority index is not included in the DCI format and is low priory by default.
· for the first DCI format for GC-PDCCH, down-select from:
o Alt1: Optionally configured to be included in the DCI format. If not configured, the priority index is not included in the DCI format and is low priory by default.
o Alt2: Always low priority, i.e., the priority index is not included in the DCI format.
Agreement:
The priority of multicast for NACK-only based feedback is the same as the priority of unicast for the same priority index of HARQ-ACK.
Agreement:
When more than one NACK-only based feedback are available for transmission in the same PUCCH slot, down-select from the following alternatives:
· Alt1: Support UE multiplexing the HARQ-ACK bits by transforming NACK-only into ACK/NACK HARQ bits.
· Alt2: Support sub-slot based PUCCH for this case.
· Alt3: Support UE transmitting more than one slot-based PUCCHs in the same PUCCH slot.
· Alt4: Define combination of NACK-only which corresponds to a specific sequence or a PUCCH transmission.
· Alt5: NACK-only bundling
Agreement:
When UE supports and is configured with more than one G-RNTI,
· for Type-2 codebook construction, DAI is separately counted per G-RNTI.
· Type-2 codebook is constructed by concatenating Type-2 sub-codebook of each RNTI following the ascending order of the G-RNTI value.
R1-2108553 FL summary#6 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
From GTW session:
Agreement:
Update the WA made in RAN1#105-e meeting regarding enabling/disabling HARQ-ACK feedback as follows:
Working assumption:
For enabling/disabling ACK/NACK-based HARQ-ACK feedback for RRC_CONNECTED UE receiving multicast via dynamic group-common PDSCH:
· RRC signaling configures the enabling/ disabling function of group-common DCI indicating the enabling /disabling ACK/NACK based HARQ-ACK feedback.
o If RRC signaling configures the function of group-common DCI based indication, group-common DCI indicates (explicitly or implicitly) whether ACK/NACK based HARQ-ACK feedback is enabled/disabled
o Otherwise, enabling/disabling ACK/NACK based HARQ-ACK feedback is configured by RRC signaling.
o FFS details on RRC signaling and group-common DCI indicating.
· FFS whether/how this option is extended to apply to NACK-only based feedback and multiple G-RNTI cases.
· FFS the relation to the HARQ-ACK codebook types and HARQ-ACK codebook construction.
· FFS the relation to the enabling/disabling ACK/NACK based HARQ-ACK feedback for retransmission.
· FFS whether/how to allow UE not to react to the DCI signaling, but instead follow UE-specific RRC configuration for HARQ feedback.
· FFS whether/how to apply it to SPS group-common PDSCH.
· UE capability for enabling/ disabling function of group-common DCI indicating the enabling /disabling ACK/NACK based HARQ-ACK feedback is introduced and FFS details.
· Note: It is up to network implementation to avoid any potential HARQ ACK mismatch between different UEs in the same multicast group
Agreement
For UE supports both ACK/NACK-based and NACK-only based HARQ-ACK feedback for multicast SPS PDSCH without PDCCH scheduling, select one or more of the following alternatives:
· Alt1: HARQ-ACK feedback option is configured per SPS configuration index.
· Alt2: HARQ-ACK feedback option is indicated in the SPS activation DCI.
· Note: enabling/disabling HARQ-ACK feedback for multicast SPS can be discussed separately.
Final summary in R1-2108641.
R1-2106440 Discussion on UE receiving broadcast in RRC IDLE/INACTIVE state Huawei, HiSilicon, CBN
R1-2106625 Discussion on basic functions for broadcast multicast for RRC_IDLE RRC_INACTIVE UEs vivo
R1-2106664 Basic Functions for Broadcast / Multicast for RRC_IDLE / RRC_INACTIVE Ues Nokia, Nokia Shanghai Bell
R1-2106718 Basic Functions for Broadcast or Multicast for RRC_IDLE or RRC_INACTIVE UEs Spreadtrum Communications
R1-2106747 Discussion on basic Functions for Broadcast or Multicast for RRC_IDLE or RRC_INACTIVE UEs ZTE
R1-2106821 Considerations on MBS functions for RRC_IDLE/INACTIVE UEs Sony
R1-2106914 On basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs Samsung
R1-2106947 Discussion on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs CATT, CBN
R1-2107095 MBS Support for RRC IDLE/INACTIVE UEs FUTUREWEI
R1-2107162 Basic functions for broadcast/multicast in idle/inactive states Lenovo, Motorola Mobility
R1-2107165 Search Space and DCI Design for MBS in IDLE and INACTIVE states TCL Communication Ltd.
R1-2107231 Discussion on basic functions for RRC_IDLE/RRC_INACTIVE UEs OPPO
R1-2107371 Views on group scheduling for Broadcast RRC_IDLE/INACTIVE UEs Qualcomm Incorporated
R1-2107384 Discussion on MBS for RRC_IDLE/RRC_INACTIVE UEs Google Inc.
R1-2107427 Discussion on NR MBS in RRC_IDLE/ RRC_INACTIVE states CMCC
R1-2107458 Basic function for broadcast/multicast LG Electronics
R1-2107516 Discussion on MBS for RRC_IDLE/INACTIVE UEs MediaTek Inc.
R1-2107613 NR-MBS for RRC_IDLE/INACTIVE UEs Intel Corporation
R1-2107765 Discussion on MBS for RRC_IDLE and RRC_INACTIVE UEs Apple
R1-2107883 Discussion on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs NTT DOCOMO, INC.
R1-2107952 NR MBS related discussion for RRC_IDLE/RRC_INACITVE UEs CHENGDU TD TECH LTD.
R1-2108028 Discussion on MBS for RRC_IDLE/RRC_INACTIVE UEs Convida Wireless
R1-2108172 Support for NR
multicast reception in RRC Inactive/Idle Ericsson
[106-e-NR-MBS-03] – David (BBC)
Email discussion/approval on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs and the LS in R1-2106410 (from AI5) including any reply LS as necessary with checkpoints for agreements on August 19, 24 and 27
R1-2108228 Feature Lead summary #2 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/RRC_INACTIVE states Moderator (BBC) (rev of R1-2108227)
From GTW session:
Agreement:
From RAN1 perspective, the CFR for broadcast reception of RRC_IDLE/INACTIVE UEs, includes at least the following configurations:
· One set of parameters configured for PDSCH for broadcast reception with GC-PDSCH
· One set of parameters configured for PDCCH for broadcast reception with GC-PDCCH
· FFS: whether some parameters configured for PDSCH/PDCCH are optional/needed for the supported cases of CFR.
· FFS: If necessary, depending on the cases supported, starting PRB and the number of PRBs
o The reference for starting PRB is Point A. (Following the same approach to determine reference for starting PRB as that defined in AI8.12.1.)
Decision: As per email decision posted on Aug 22nd,
There is no specification support in Rel-17 for broadcast reception with RRC_IDLE/RRC_INACTIVE UEs with configured/defined CFRs for group-common PDCCH/PDSCH with smaller size than the initial BWP, where the initial BWP has the same frequency resources as CORESET0 (i.e., Case B).
Agreement:
For RRC_IDLE/RRC_INACTIVE UEs, for broadcast reception, if searchSpace#0 is configured for MTCH, the mapping between PDCCH occasions and SSBs is the same as for SIB1.
R1-2108230 Feature Lead summary #4 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/RRC_INACTIVE states Moderator (BBC) (rev of R1-2108229)
From GTW session:
Agreement:
Study and reach an agreement by RAN1#106b-e on whether Alt1 and Alt2 for MCCH change notification indication can accommodate at least 2 bits for the notification of MCCH configuration changes due to a session start and the notification of MCCH configuration changes of an ongoing session (including session stop).
Agreement:
The DCI format for GC-PDCCH scheduling a GC-PDSCH carrying MCCH/MTCH at least includes the following fields for broadcast reception with UEs in RRC_IDLE/INACTIVE state:
Agreement
Only one CFR can be configured for group-common PDCCH/PDSCH carrying MCCH for broadcast reception with UEs in RRC_IDLE/INACTIVE state.
Agreement
For broadcast reception with UEs in RRC_IDLE/INACTIVE state, the DCI size of GC-PDCCH scheduling a GC-PDSCH carrying MCCH/MTCH is aligned with DCI format 1_0 with CRC scrambled by C-RNTI in the CSS.
R1-2108578 Feature Lead summary #5 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/RRC_INACTIVE states Moderator (BBC)
From GTW session:
Proposal:
For a configured/defined CFR for GC-PDCCH/PDSCH carrying MCCH and MTCH for broadcast reception with UEs in RRC IDLE/INACTIVE state.
Objected by Lenovo
Decision: As per email decision posted on Aug 27th,
For broadcast reception, RRC_IDLE/RRC_INACTIVE UEs can use the same bandwidth configurations for the CFR of GC-PDCCH/PDSCH carrying MCCH and the CFR of GC-PDCCH/PDSCH carrying MTCH.
Conclusion:
For broadcast reception with RRC_IDLE/RRC_INACTIVE UEs, there is no specification support in Rel-17 of different CSS types for GC-PDCCH scheduling MCCH and MTCH.
Agreement:
Study whether the Type-x CSS supported for multicast in RRC_CONNECTED can be reused as baseline for broadcast in RRC_IDLE/RRC_INACTIVE for GC-PDCCH scheduling MCCH and MTCH.
Agreement:
For RRC_IDLE/RRC_INACTIVE UEs with broadcast reception, if common search space other than searchSpace#0 is configured for MTCH, the mapping of PDCCH monitoring occasions to SSBs can be configured with a rule.
Final summary in R1-2108579.
R1-2106626 Other issues for Rel-17 MBS vivo
R1-2106665 Other Aspects for Rel-17 MBS Nokia, Nokia Shanghai Bell
R1-2106748 Consideration on potential further enhancement for MBS ZTE
R1-2106948 Discussion on other issues in Rel-17 MBS CATT
R1-2107459 Other aspects for MBS LG Electronics
R1-2107662 Impact from MCCH and MTCH on broadcast reception Huawei, HiSilicon
R1-2107953 Other aspects for NR MBS CHENGDU TD TECH LTD.
R1-2108173 Assumptions for performance evaluations of NR-MBS Ericsson
Please refer to RP-201038 for detailed scope of the WI.
Please also refer to section 5.1 of RP-212559 for additional guidance for this e-meeting.
R1-2110619 Session notes for 8.12 (NR Multicast and Broadcast Services) Ad-Hoc Chair (Ericsson)
[106bis-e-R17-RRC-MBS] – Fei (CMCC)
Email discussion on Rel-17 RRC parameters for NR MBS
- 1st check point: October 14
- Final check point: October 19
R1-2110694 Summary of email discussion on Rel-17 RRC parameters for NR MBS Moderator (CMCC, Huawei, BBC)
Document is noted. For consolidation under 8 in [106bis-e-R17-RRC].
R1-2110696 Agreements for NR MBS up to RAN1#106b WI rapporteur (CMCC)
R1-2108723 Resource configuration and group scheduling for RRC_CONNECTED UEs Huawei, HiSilicon, CBN
R1-2108804 Group Scheduling Aspects for Connected UEs FUTUREWEI
R1-2108851 Discussion on Mechanisms to Support Group Scheduling for RRC_CONNECTED UEs ZTE
R1-2108926 Discussion on MBS group scheduling for RRC_CONNETED UEs Spreadtrum Communications
R1-2109001 Discussion on mechanisms to support group scheduling for RRC_CONNECTED Ues vivo
R1-2109067 Discussion on group Scheduling mechanism for RRC_CONNECTED UEs OPPO
R1-2109135 Discussion on Group Scheduling Mechanisms for RRC_CONNECTED Ues NEC
R1-2109194 Discussion on group scheduling mechanism for RRC_CONNECTED UEs in MBS CATT
R1-2109302 Summary#1 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
R1-2109303 Discussion on group scheduling mechanisms CMCC
R1-2109316 Group Scheduling Mechanisms to Support 5G Multicast / Broadcast Services for RRC_CONNECTED Ues Nokia, Nokia Shanghai Bell
R1-2109387 Discussion on mechanisms to support group scheduling for RRC_CONNECTED UE Xiaomi
R1-2109515 Support of group scheduling for RRC_CONNECTED UEs Samsung
R1-2109538 On group scheduling mechanism for RRC_CONNECTED UEs Lenovo, Motorola Mobility
R1-2109567 Discussion on NR MBS group scheduling for RRC_CONNECTED UEs MediaTek Inc.
R1-2109633 NR-MBS Group Scheduling for RRC_CONNECTED UEs Intel Corporation
R1-2109701 Discussion on group scheduling mechanism for RRC_CONNECTED UEs NTT DOCOMO, INC.
R1-2109767 Group scheduling related questions for RRC_CONNECTED UEs TD Tech
R1-2109823 Discussion on group scheduling mechanism for RRC_CONNECTED UEs FGI, Asia Pacific Telecom
R1-2109983 Support of group scheduling for RRC_CONNECTED UEs LG Electronics
R1-2110056 Discussion on group scheduling mechanism for RRC_CONNECTED UEs Apple
R1-2110074 Discussion on common frequency resource configuration for multicast of RRC_CONNECTED UEs ETRI
R1-2110118 Discussion on group scheduling mechanism for RRC_CONNECTED UEs Convida Wireless
R1-2110210 Views on group scheduling for Multicast RRC_CONNECTED UEs Qualcomm Incorporated
R1-2110249 Discussion on group scheduling mechanism for RRC_CONNECTED UEs Google Inc.
R1-2110255 Discussion on mechanisms to support group scheduling for RRC_CONNECTED UEs ASUSTeK
R1-2110355 Mechanisms to support MBS group scheduling for RRC_CONNECTED Ues Ericsson
[106bis-e-NR-MBS-01] – Fei (CMCC)
Email discussion/approval on mechanisms to support group scheduling for RRC_CONNECTED UEs with checkpoints for agreements on October 14 and 19
R1-2110465 Summary#2 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
From Oct 12th GTW session
Agreement:
The starting PRB and the length of PRBs of CFR are jointly indicated reusing the RIV indication mechanism in the same way as locationAndBandwidth of a BWP.
Agreement:
RBG and PRG for multicast GC-PDSCH in CFR are defined using the same procedure as for unicast PDSCH in DL BWP.
· For RBG, the size is defined based on the starting PRB of the CFR, size of the CFR and the higher layer parameter rbg-Size configured by PDSCH-Config for multicast in the CFR.
· For PRG, the size is defined based on the starting PRB of the CFR, size of the CFR and precoding granularity for multicast which can be equal to one of the values among {2, 4, wideband}.
· Note: Whether the RBG and PRG size for multicast (configured directly or indirectly) is the same as for unicast can be discussed separately.
R1-2110466 Summary#3 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
R1-2110467 Summary#4 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
From Oct 15th GTW session
Agreement:
The number of CFRs for multicast is no more than one per dedicated unicast BWP in Rel-17.
Agreement:
For LBRM and TBS determination for GC-PDSCH, the default value of the maximum number of layers is 1 if maxMIMO-Layers in PDSCH-Config for MBS in CFR is not configured.
Agreement:
For determination of maximum modulation order for LBRM and TBS determination for GC-PDSCH,
· if mcs-Table in PDSCH-Config for MBS is not configured in CFR, Table 5.1.3.1-1 in TS38.214 is used (similar as the default value in R16).
Agreement:
For multicast of RRC_CONNECTED UEs, the G-RNTI(s) is/are configured
· Opt.2: per serving cell.
· FFS G-CS-RNTI(s)
Agreement:
The ‘TPC command for scheduled PUCCH’ field is not needed for the first DCI format for multicast.
· FFS: Whether the field should be reserved or should be removed.
Agreement:
The ‘TPC command for scheduled PUCCH’ field is not needed for the second DCI format for multicast.
· FFS: Whether the field should be reserved or should be removed.
Agreement:
The first and second DCI formats for multicast can be configured in the same or different search space sets belonging to type-x CSS.
Agreement:
For FDRA determination of the first DCI format for GC-PDCCH, Option 2 is supported.
· Option 2:
o
is
given by
§ the size of CORESET 0 if CORESET 0 is configured for the cell; and
§ the size of initial DL bandwidth part if CORESET 0 is not configured for the cell.
o For resource indication value (RIV) of downlink resource allocation type 1, the similar scheme as for the case that the DCI size for DCI format 1_0 in USS is derived from the size of DCI format 1_0 in CSS but applied to an active BWP is used.
§
If the size of CFR (i.e. 
) is larger than the size of CORESET0/initial DL bandwidth part, the
resource indication value (RIV) is defined as
in section 5.1.2.2.2 in TS38.214, where K is the maximum value from set
{1, 2, 4, 6, 8, 10, 12} which satisfies 
;otherwise, 
Agreement:
For GC-PDSCH scheduled with the first DCI format for multicast, RB numbering starts from the lowest RB of the CFR.
Agreement:
For initializing scrambling sequence
generator for GC-PDCCH with the second DCI format for
RRC_CONNECTED UEs, 
=0.
Agreement:
For initializing scrambling sequence generator for GC-PDSCH scheduled by the first DCI format for multicast received in Type-x CSS for RRC_CONNECTED UEs,
·
equals the higher layer parameter dataScramblingIdentityPDSCH if it is configured in PDSCH-Config in a CFR used for GC-PDSCH and the RNTI equals the G-RNTI or
G-CS-RNTI; 
otherwise.
·
corresponds to the RNTI associated with the GC-PDSCH transmission
(i.e., the G-RNTI used by the scheduling GC-PDCCH, or the G-CS-RNTI used by the
SPS GC-PDSCH activation PDCCH)
Agreement:
For initializing sequence generator for DMRS of GC-PDSCH,
·
and 
are given by the higher-layer parameters scramblingID0 and scramblingID1,
respectively, in the DMRS-DownlinkConfig IE if provided in PDSCH-Config
in a CFR used for GC-PDSCH and the GC-PDSCH is scheduled by GC-PDCCH using
the second DCI format
·
is given by the higher-layer
parameter scramblingID0 if provided in PDSCH-Config in a CFR used for GC-PDSCH and the GC-PDSCH is scheduled by GC-PDCCH using the first
DCI format;
·
otherwise;
·
FFS: 
is given by the DM-RS sequence initialization field, if present, in
the DCI associated with the GC-PDSCH transmission if second
DCI format is used, otherwise 
.
R1-2110543 Summary#5 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
From Oct 18th GTW session
Agreement:
The association between a G-CS-RNTI and a SPS-Config-Multicast is indicated by the activation GC-PDCCH for SPS GC-PDSCH, i.e., a value of the HARQ process number field in a DCI format indicates an activation for a SPS GC-PDSCH configuration for multicast with a same value as provided by sps-ConfigIndex in a SPS-Config-Multicast.
R1-2110544 Summary#6 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
Decision: As per email decision posted on Oct 20th,
Agreement:
For initializing scrambling sequence generator for GC-PDCCH with the first DCI format for RRC_CONNECTED UEs,
·
equals the higher layer parameter pdcch-DMRS-ScramblingID if
it is configured in the CORESET configured within CFR-Config-Multicast for the
GC-PDCCH; 
otherwise.
·
= 0.
Agreement:
For initializing sequence generator for DMRS of GC-PDCCH with the first DCI format received in Type-x CSS for RRC_CONNECTED UEs,
·
equals the higher layer parameter pdcch-DMRS-ScramblingID
if it is configured in the CORESET configured within CFR-Config-Multicast for
the GC-PDCCH; 
otherwise.
Agreement:
Study the following options for the LBRM/TBS determination for PTP retransmission of multicast.
· Option 1: based on the LBRM/TBS determination of the PTM initial transmission using same HPID and NDI.
· Option 2: based on the LBRM/TBS determination of the legacy unicast PDSCH transmission.
Final summary in R1-2110637.
R1-2108724 Mechanisms to improve reliability for RRC_CONNECTED UEs Huawei, HiSilicon, CBN
R1-2108805 Further Discussions on Reliability for RRC_CONNECTED UEs FUTUREWEI
R1-2108852 Discussion on Mechanisms to Improve Reliability for RRC_CONNECTED UEs ZTE
R1-2108927 Mechanisms to improve MBS reliability for RRC_CONNECTED UEs Spreadtrum Communications
R1-2109002 Discussion on mechanisms to improve reliability for RRC_CONNECTED Ues vivo
R1-2109068 UL feedback for RRC-CONNECTED UEs in MBS OPPO
R1-2109136 Discussion on Reliability Improvements for RRC_CONNECTED UEs NEC
R1-2109195 Discussion on reliability improvement mechanism for RRC_CONNECTED UEs in MBS CATT
R1-2109304 Discussion on reliability improvement CMCC
R1-2109317 Reliability Improvements for RRC_CONNECTED UEs Nokia, Nokia Shanghai Bell
R1-2109516 On mechanisms to improve reliability for RRC_CONNECTED UEs Samsung
R1-2109539 On reliability improvement for RRC-CONNECTED UEs Lenovo, Motorola Mobility
R1-2109568 Discussion on mechanisms to improve reliability for RRC_CONNECTED UEs MediaTek Inc.
R1-2109634 Mechanisms to Improve Reliability of NR-MBS for RRC_CONNECTED UEs Intel Corporation
R1-2109702 Discussion on mechanisms to improve reliability for multicast for RRC_CONNECTED UEs NTT DOCOMO, INC.
R1-2109768 PUCCH formats for NACK-ONLY based HARQ-ACK feedback TD Tech
R1-2109984 Mechanisms to improve reliability of Broadcast/Multicast service LG Electronics
R1-2110057 Discussion on MBS reliability improvement for RRC_CONNECTED UEs Apple
R1-2110075 Discussion on HARQ-ACK feedback mechanism for multicast of RRC_CONNECTED UEs ETRI
R1-2110119 Discussion on reliability enhancement for RRC_CONNECTED UEs Convida Wireless
R1-2110211 Views on UE feedback for Multicast RRC_CONNECTED UEs Qualcomm Incorporated
R1-2110250 Discussion on MBS reliability for RRC_CONNECTED UEs Google Inc.
R1-2110356 Mechanisms to improve reliability for RRC_CONNECTED Ues Ericsson
[106bis-e-NR-MBS-02] – Jinhuan (Huawei)
Email discussion/approval on mechanisms to improve reliability for RRC_CONNECTED UEs with checkpoints for agreements on October 14 and 19
R1-2110408 FL summary#1 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
From Oct 12th GTW session
Agreement:
The group-common DCI indicating the enabling/disabling ACK/NACK based HARQ-ACK feedback is configured per G-RNTI by UE RRC signalling.
Agreement:
If the group-common DCI indicating the enabling/disabling ACK/NACK based HARQ-ACK feedback is not configured, enabling/disabling ACK/NACK based HARQ-ACK feedback is configured per G-RNTI by UE RRC signalling.
R1-2110493 FL summary#2 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
From Oct 14th GTW session
Agreement:
When PUCCH transmission for the NACK-only based feedback for multicast collides with PUCCH transmissions for HARQ-ACK feedback/CSI for unicast for the same priority or PUSCH transmission for the same priority, support UE multiplexing the NACK-only based feedback with the HARQ-ACK feedback/CSI on PUCCH or on to PUSCH by transforming NACK-only into the ACK/NACK HARQ bit.
· This applies to at least the case of the feedback addressing one TB. NACK-only based feedback for more than one TBs is to be handled separately.
· Note: When the TB is correctly decoded, the ACK will be transmitted and multiplexed with others.
· FFS the case of PUCCH for SR.
Agreement:
When more than one NACK-only based feedback are available for transmission in the same PUCCH slot, further decide based on the following subset of alternatives (from previous agreement) with potential further down-selection:
· Alt1: Support UE multiplexing the HARQ-ACK bits by transforming NACK-only into ACK/NACK HARQ bits.
·
Alt2:
Support sub-slot based PUCCH for this case.
·
Alt3:
Support UE transmitting more than one slot-based PUCCHs in the same PUCCH slot.
· Alt4: Define combination of NACK-only which corresponds to a specific sequence or a PUCCH transmission.
·
Alt5:
NACK-only bundling
Decision: As per email decision posted on Oct 15th,
Agreement:
Confirm the WA made in RAN1#106-e meeting regarding enabling/disabling HARQ-ACK feedback.
Agreement:
For group-common DCI indicating whether ACK/NACK based HARQ-ACK feedback is enabled/disabled, down-select from the following alternatives:
· Alt1: Reuse one existing field in the group-common DCI.
· Alt2: Introduce a new field in the group-common DCI.
R1-2110526 FL summary#3 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
From Oct 15th GTW session
Agreement:
For multicast SPS PDSCH without PDCCH scheduling, HARQ-ACK feedback option is configured by UE RRC signalling.
· FFS: Whether the configuration is per SPS configuration index or per G-CS-RNTI.
· Note: Whether there is a UE capability for support of NACK-only based HARQ-ACK or not will be discussed as part of UE features discussion.
Agreement:
· If configured, the pdsch-AggregationFactor for multicast dynamic scheduling is configured per G-RNTI.
· If configured, the pdsch-AggregationFactor for multicast SPS is configured per SPS-Config-Multicast.
Agreement:
For slot-level repetition for SPS GC-PDSCH for multicast RRC_CONNECTED UEs.
· Config A or Config B can be configured to UE:
o (Config A) UE can be optionally configured with pdsch-AggregationFactor per SPS-Config-Multicast.
o (Config B) UE can be optionally configured with TDRA table with repetitionNumber as part of the TDRA table in PDSCH-Config-Multicast. If UE is configured with Config B, UE does not expect to be configured with Config A for the same SPS group-common PDSCH.
· For Config A, if pdsch-AggregationFactor in SPS-Config-Multicast is not configured, default value is
o Alt1: equal to 1.
Agreement:
For UE supporting both ACK/NACK based and NACK-only based feedback for multicast, for the same G-RNTI, support the following
o Note: Case1-1: if configured with ACK/NACK based feedback, UE can be optionally configured a separate PUCCH-Config/PUCCH-ConfigurationList for multicast. Otherwise, PUCCH-Config/PUCCH-ConfigurationList for unicast applies (This has been agreed.)
o Case 1-2: if configured with NACK-only based feedback, when separate PUCCH-Config/PUCCH-ConfigurationList for NACK-only is not configured, PUCCH-Config/PUCCH-ConfigurationList for unicast applies.
R1-2110545 FL summary#4 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
From Oct 18th GTW session
Agreement:
For the priority index for the first DCI format for GC-PDCCH, support the following Alt2 from the previous agreement:
·
Alt1: Optionally
configured to be included in the DCI format. If not configured, the priority
index is not included in the DCI format and is low priory by default.
· Alt2: Always low priority, i.e., the priority index is not included in the DCI format.
Agreement:
For TDM-ed unicast and multicast, for Type-1 HARQ-ACK codebook construction for ACK/NACK-based unicast and multicast to be multiplexed in the same PUCCH resource, determining PDSCH reception candidate occasions can be configured between the following alternatives from the previous agreement:
· Alt 1:
o
for slot timing values 
in the intersection of set for unicast (termed
set A) and set for multicast (termed set B), based on union of the PDSCH
TDRA sets,
o
for slot timing values in set A but not in set B, based on PDSCH TDRA set
for unicast, and
o
for slot timing values 
in set B but not in set A, based on PDSCH TDRA set
for multicast.
·
Alt 2: for slot timing
values in the union of set for unicast and set for multicast, based on the union of the PDSCH TDRA sets.
· Support of Alt. 1 is a UE capability
R1-2110583 FL summary#5 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
From Oct 19th GTW session
Agreement:
For multiplexing the ACK/NACK-based HARQ-ACK feedback for multicast and unicast, determining the PUCCH resources for transmission is based on the PRI indicated in the “last DCI”, where the “last DCI” refers to the following Alt1 from the previous agreement:
· Alt.1: The last DCI for unicast
· FFS: Any details when last DCI is missed by the UE if it is necessary to make them different from current specifications for this case.
Final summary in R1-2110646.
R1-2108725 Discussion on UE receiving broadcast in RRC IDLE/INACTIVE state Huawei, HiSilicon, CBN
R1-2108806 MBS Support for RRC IDLE/INACTIVE UEs FUTUREWEI
R1-2108853 Discussion on basic Functions for Broadcast or Multicast for RRC_IDLE or RRC_INACTIVE UEs ZTE
R1-2108928 Basic Functions for Broadcast or Multicast for RRC_IDLE or RRC_INACTIVE UEs Spreadtrum Communications
R1-2109003 Remaining issues on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE Ues vivo
R1-2109069 Discussion on basic functions for RRC_IDLE/RRC_INACTIVE UEs OPPO
R1-2109196 Discussion on basic functions for broadcast multicast for RRC_IDLE RRC_INACTIVE UEs CATT
R1-2109305 Discussion on NR MBS in RRC_IDLE/ RRC_INACTIVE states CMCC
R1-2109318 Basic Functions for Broadcast / Multicast for RRC_IDLE / RRC_INACTIVE Ues Nokia, Nokia Shanghai Bell
R1-2109388 Discussion on basic functions for broadcast/multicast for RRC_IDLERRC_INACTIVE UEs Xiaomi
R1-2109517 On basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs Samsung
R1-2109540 Basic functions for broadcast/multicast in idle/inactive states Lenovo, Motorola Mobility
R1-2109569 Discussion on MBS for RRC_IDLE/INACTIVE UEs MediaTek Inc.
R1-2109635 NR-MBS for RRC_IDLE/INACTIVE UEs Intel Corporation
R1-2109703 Discussion on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs NTT DOCOMO, INC.
R1-2109769 Further discussion on basic functions for RRC_IDLE/RRC_INACTIVE UEs TD Tech, Chengdu TD Tech
R1-2109802 Considerations on MBS functions for RRC_IDLE/INACTIVE UEs Sony
R1-2109985 Basic function for broadcast/multicast LG Electronics
R1-2110058 Discussion on MBS for RRC_IDLE and RRC_INACTIVE UEs Apple
R1-2110120 Discussion on MBS for RRC_IDLE/RRC_INACTIVE UEs Convida Wireless
R1-2110212 Views on group scheduling for Broadcast RRC_IDLE/INACTIVE UEs Qualcomm Incorporated
R1-2110251 Discussion on MBS for RRC_IDLE/RRC_INACTIVE UEs Google Inc.
R1-2110258 Discussion on basic functions for broadcast or multicast for RRC_IDLE and RRC_INACTIVE UEs ASUSTeK
R1-2110357 Support for NR multicast reception in RRC Inactive/Idle Ericsson
[106bis-e-NR-MBS-03] – David (BBC)
Email discussion/approval on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs with checkpoints for agreements on October 14 and 19
R1-2110409 Feature Lead summary #1 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/RRC_INACTIVE states Moderator (BBC)
From Oct 14th GTW session
Agreement:
For RRC_IDLE/RRC_INACTIVE UEs, for broadcast reception, both searchSpace#0 and common search space other than searchSpace#0 can be configured for GC-PDCCH scheduling MTCH.
Agreement:
The PDCCH/PDSCH parameters for broadcast reception with GC-PDCCH/PDSCH, which are not configured, use as default the value of the PDCCH/PDSCH parameters for the configuration of the Rel-15/Rel-16 initial BWP for RRC_IDLE/RRC_INACTIVE UEs.
Agreement:
For initializing scrambling sequence generator for GC-PDCCH for MCCH/MTCH for broadcast,
·
equals the higher layer parameter pdcch-DMRS-ScramblingID if
it is configured in a CFR used for the GC-PDCCH for MCCH/MTCH; 
otherwise.
·
R1-2110410 Feature Lead summary #2 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/RRC_INACTIVE states Moderator (BBC)
From Oct 15th GTW session
Working assumption:
Alt 2 (from previous agreement) is supported for broadcast reception with RRC_IDLE/RRC_INACTIVE UEs for the notification of MCCH configuration changes.
· Send an LS to RAN2 with the mechanism agreed in RAN1
Decision: As per email decision posted on Oct 15th,
Agreement:
For broadcast reception with UEs in RRC_IDLE/INACTIVE states, support slot-level repetition for MTCH.
Agreement:
For initializing scrambling sequence generator for GC-PDSCH for MCCH/MTCH for broadcast,
·
equals the higher layer parameter dataScramblingIdentityPDSCH
if it is configured in a CFR used for GC-PDSCH for MCCH/MTCH and the RNTI
equals the G-RNTI or MCCH-RNTI; 
otherwise.
·
corresponds
to the RNTI associated with the GC-PDSCH transmission.
Agreement:
For initializing sequence generator for DMRS of GC-PDCCH for MCCH/MTCH for broadcast,
·
equals the higher layer parameter pdcch-DMRS-ScramblingID
if it is configured in a CFR used for the GC-PDCCH for MCCH/MTCH; 
otherwise.
Agreement:
For initializing sequence generator for DMRS of GC-PDSCH for MCCH/MTCH for broadcast,
·
equals the higher-layer parameters scramblingID0 if
it is configured in the DMRS-DownlinkConfig IE in a CFR used for
GC-PDSCH for MCCH/MTCH; 
otherwise.
R1-2110411 Feature Lead summary #3 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/RRC_INACTIVE states Moderator (BBC)
From Oct 18th GTW session
Proposal:
For a configured/defined CFR for GC-PDCCH/PDSCH carrying MCCH and MTCH for broadcast reception with UEs in RRC IDLE/INACTIVE state.
R1-2110412 Feature Lead summary #4 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/RRC_INACTIVE states Moderator (BBC)
From Oct 19th GTW session
Proposal:
For a configured/defined CFR for GC-PDCCH/PDSCH carrying MCCH and MTCH for broadcast reception with UEs in RRC IDLE/INACTIVE state.
Objection sustained by: Lenovo, CMCC, Xiaomi, Spreadtrum, OPPO
Proposal:
For a configured/defined CFR for GC-PDCCH/PDSCH carrying MCCH and MTCH for broadcast reception with UEs in RRC IDLE/INACTIVE state.
Objection sustained by: Nokia Shanghai Bell, ZTE, vivo, LG Electronics, Qualcomm
Decision: As per email decision posted on Oct 20th,
Agreement:
For RRC_IDLE/RRC_INACTIVE UEs for broadcast reception, MTCH scheduling is associated with a window defined by the MTCH monitoring periodicity and the starting of the periodicity
· FFS: the window is associated to one or multiple or all G-RNTI.
Agreement:
For RRC_IDLE/RRC_INACTIVE UEs for broadcast reception, at least support that within the MTCH scheduling window, the association between the PDCCH monitoring occasions and SSB is defined as:
· the [x×N+K]th PDCCH monitoring occasion(s) for MTCH in the scheduling window corresponds to the Kth transmitted SSB, where x = 0, 1, ...X-1, K = 1, 2, …N, N is the number of actual transmitted SSBs determined according to ssb-PositionsInBurst in SIB1 and X is equal to CEIL(number of PDCCH monitoring occasions in MTCH transmission window/N).
· For the purpose of associating PDCCH monitoring occasion for MTCH and SSB, the UE assumes that, in the MTCH scheduling window, PDCCH for an MTCH scrambled by G-RNTI is transmitted in at least one PDCCH monitoring occasion corresponding to each transmitted SSB.
Final summary in R1-2110595.
R1-2108854 Consideration on potential further enhancement for MBS ZTE
R1-2109004 Other issues for Rel-17 MBS vivo
R1-2109197 Discussion on other issues in Rel-17 MBS CATT
R1-2109319 Other Aspects for Rel-17 MBS Nokia, Nokia Shanghai Bell
R1-2109389 Discussion on remaining issues for idle and inactive UE Xiaomi
R1-2109742 Impact from MCCH and MTCH on broadcast reception Huawei, HiSilicon
R1-2109770 Discussion on typical configuration for NR MBS CHENGDU TD TECH LTD.
R1-2109986 Other aspects for MBS LG Electronics
R1-2110358 Assumptions for performance evaluations of NR-MBS Ericsson
Please refer to RP-201038 for detailed scope of the WI.
Please also refer to section 5.1 of RP-212559 for additional guidance for this e-meeting.
R1-2112797 Session notes for 8.12 (NR Multicast and Broadcast Services) Ad-Hoc Chair (Huawei)
Rel-17 CRs related to MBS
R1-2112435 Introduction of support for multicast and broadcast services Ericsson
Decision: Draft CR to 38.211 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.
R1-2112445 Introduction of multicast-broadcast services in NR Samsung
Decision: Draft CR to 38.213 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.
R1-2112471 Introduction of NR Multicast and Broadcast Services Huawei
Decision: Draft CR to 38.212 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.
R1-2112485 Introduction of NR Multicast and Broadcast Services Nokia
Decision: Draft CR to 38.214 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.
R1-2112515 Introduction of multicast and broadcast services Qualcomm
Decision: Draft CR to 38.202 inc. agreements up to RAN1#106b-e. Endorsed, and to be revised to final CR for RAN submission after RAN1#107-e.
[107-e-R17-RRC-MBS] – Fei (CMCC)
Email discussion on Rel-17 RRC parameters for NR MBS by November 19
- Email discussion to start on November 15
R1-2112969 Summary of email discussion on Rel-17 RRC parameters for NR MBS Moderator (CMCC, Huawei, BBC) (rev of R1-2112869)
Document is noted. For consolidation under 8 in [107-e-R17-RRC].
R1-2112892 Agreements for NR MBS up to RAN1#107 WI rapporteur (CMCC)
R1-2110777 Resource configuration and group scheduling for RRC_CONNECTED UEs Huawei, HiSilicon, CBN
R1-2110889 Remaining Issues on MBS for Connected UEs FUTUREWEI
R1-2110895 Further discussion on group scheduling for multicast mode TD Tech, Chengdu TD Tech
R1-2110910 Discussion on Mechanisms to Support Group Scheduling for RRC_CONNECTED UEs ZTE
R1-2111039 Remaining issues on mechanisms to support group scheduling for RRC_CONNECTED Ues vivo
R1-2111113 Discussion on MBS group scheduling for RRC_CONNETED UEs Spreadtrum Communications
R1-2111135 Group Scheduling Mechanisms to Support 5G Multicast / Broadcast Services for RRC_CONNECTED UEs Nokia, Nokia Shanghai Bell
R1-2111230 Discussion on group scheduling mechanism for RRC_CONNECTED UEs in MBS CATT
R1-2111303 Discussion on group Scheduling mechanism for RRC_CONNECTED UEs OPPO
R1-2111516 NR-MBS Group Scheduling for RRC_CONNECTED UEs Intel Corporation
R1-2111549 Discussion on mechanisms to support group scheduling for RRC_CONNECTED UEs Xiaomi
R1-2111627 Discussion on group scheduling mechanisms CMCC
R1-2111695 Discussion on Group Scheduling Mechanisms for RRC_CONNECTED UEs NEC
R1-2111761 Support of group scheduling for RRC_CONNECTED UEs Samsung
R1-2111897 Discussion on group scheduling mechanism for RRC_CONNECTED UEs Apple
R1-2112063 Support of group scheduling for RRC_CONNECTED UEs LG Electronics
R1-2112080 Discussion on mechanisms to support group scheduling for RRC_CONNECTED UEs ASUSTeK
R1-2112128 Discussion on group scheduling mechanism for RRC_CONNECTED UEs NTT DOCOMO, INC.
R1-2112161 On group scheduling mechanism for RRC_CONNECTED UEs Lenovo, Motorola Mobility
R1-2112239 Views on group scheduling for Multicast RRC_CONNECTED UEs Qualcomm Incorporated
R1-2112312 Discussion on NR MBS group scheduling for RRC_CONNECTED UEs MediaTek Inc.
R1-2112346 Mechanisms to support MBS group scheduling for RRC_CONNECTED Ues Ericsson
R1-2112382 Discussion on group scheduling mechanism for RRC_CONNECTED UEs Google Inc.
[107-e-NR-MBS-01] – Fei (CMCC)
Email discussion/approval on mechanisms to support group scheduling for RRC_CONNECTED UEs with checkpoints for agreements on November 15 and 19
R1-2111630 Summary#1 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
From Nov 11th GTW session
Agreement
For multicast of RRC_CONNECTED UEs, the G-CS-RNTI(s) is/are configured per serving cell.
Agreement
For initializing sequence generator for
DMRS of GC-PDSCH, 
are defined using the same procedure as for unicast PDSCH.
·
given by
o if the higher-layer parameter dmrs-Downlink in the DMRS-DownlinkConfig IE in the PDSCH-Config-Multicast IE is provided
where λ is the CDM group defined in clause 7.4.1.1.2 in TS38.211.
o otherwise by
·
The quantity 
is given by the DM-RS sequence initialization field, if present, in
the DCI associated with the PDSCH transmission if multicast DCI format 1_1 is
used, otherwise 
.
Agreement
The following information is transmitted by means of the DCI format 1_0 with CRC scrambled by G-RNTI for multicast:
· Frequency domain resource assignment
· Time domain resource assignment – 4 bits as defined in Clause 5.1.2.1 of TS38.214
· VRB-to-PRB mapping – 1 bit according to Table 7.3.1.2.2-5 in TS38.212
· Modulation and coding scheme – 5 bits as defined in Clause 5.1.3 of TS38.214
· New data indicator – 1 bit
· Redundancy version – 2 bits as defined in Table 7.3.1.1.1-2 in TS38.212
· HARQ process number – [4 or 5] bits
· Downlink assignment index – 2 bits as defined in Clause 9.1.3 of TS 38.213, as counter DAI
· PUCCH resource indicator – 3 bits as defined in Clause 9.2.3 of TS38.213
· PDSCH-to-HARQ_feedback timing indicator – 3 bits as defined in Clause 9.2.3 of TS38.213
· Reserved bits –3 bits
· FFS: Some of the fields may be not useful and can be reserved in some conditions, and FFS the details of the conditions
· FFS: other fields, e.g. for HARQ enabling/disabling
Note: Whether new fields are defined for multicast DCI format 1_0 can be discussed separately. The reserved bits can be used for new fields if needed.
R1-2112540 Summary#2 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
R1-2112541 Summary#3 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
From Nov 17th GTW session
Agreement
For the LBRM/TBS determination for PTP retransmission of multicast, Option 2 is supported.
· Option 2: based on the LBRM/TBS determination of the legacy unicast PDSCH transmission
o Note: The UE is not required to soft combine the PTM initial transmission and the PTP retransmission in case of different circular buffer
§ FFS: spec impact, if any
Decision: As per email decision posted on Nov 18th,
Conclusion
For the RRC parameters that can be configured in PDSCH-Config / PDCCH-Config / SPS-Config in Rel-15/16, they can also be configured in PDSCH-Config-Multicast / PDCCH-Config-Multicast / SPS-Config-Multicast.
· If some of these RRC parameters need changes for multicast reception (e.g., modify the default values, delete some useless parameters), RAN1 will list them explicitly in the RRC parameter list that will be sent to RAN2.
· For other RRC parameters that do not need changes for multicast reception, RAN1 will not list them with postfix ‘-Multicast’ one by one in the RRC parameter list that will be sent to RAN2, and the default values of these parameters are the same as the default values of the corresponding parameters in dedicated unicast BWP.
Agreement
PRB bundle and VRB bundle for multicast GC-PDSCH in CFR are defined using the same procedure as for unicast PDSCH scheduled with unicast DCI formats 1_1 in DL BWP as defined in clause 7.3.1.6 in TS38.211. For interleaved mapping of downlink resource allocation type 1,
· the parameter Nbundle is interpreted as the number of bundles within the CFR,
· the size of the CFR is used instead of the size of the BWP,
· the starting PRB of the CFR is used instead of the starting PRB of the BWP
· the higher-layer parameter vrb-ToPRB-Interleaver in PDSCH-Config-Multicast for multicast, if provided, is used instead of the size of the higher-layer parameter vrb-ToPRB-Interleaver in PDSCH-Config for unicast.
Conclusion
For multicast of RRC-CONNECTED UEs, support CFR associated with UE active BWP, where UE active BWP can be an RRC reconfigured initial DL BWP (using Option#2 for configuring initial BWP according to the Annex B.2 of TS 38.331).
Agreement
Multicast DCI format 1_1 includes all configurable fields of unicast DCI format 1_1 except
· Identifier for DCI formats, TPC command for scheduled PUCCH, SRS request
· FFS: Scell dormancy indication
· One-shot HARQ-ACK request, PDSCH group index, New feedback indicator, Number of requested PDSCH group(s), ChannelAccess-Cpext
· CBGTI, CBGFI
· Minimum applicable scheduling offset indicator
· FFS: Carrier indicator, BWP indicator, ZP CSI-RS trigger
· FFS: MCS/NDI/RV for TB2
Conclusion
If a CFR is configured in a dedicated unicast BWP for multicast in RRC-CONNECTED state, it is up to gNB’s configuration whether to use the CORESET configured in PDCCH-config-Multicast in the CFR for unicast transmission or PTP retransmission of multicast.
Agreement
For MCS determination of SPS GC-PDSCH, mcs-Table of ‘qam64LowSE’ can be optionally configured in the SPS-Config-Multicast.
· If mcs-Table of ‘qam64LowSE’ is not configured in the SPS-Config-Multicast, the mcs-Table of PDSCH-Config-Multicast in the same CFR-Config-Multicast is used for the SPS GC-PDSCH to determine the MCS.
· If mcs-Table of ‘qam64LowSE’ is configured in the SPS-Config-Multicast, it is used for the SPS GC-PDSCH to determine the MCS.
Agreement
A list of up to 8 k1 values can be configured by higher layer parameter dl-DataToUL-ACK-MulticastDciFormat1_0 to be applied to multicast DCI format 1_0 for RRC_CONNECTED UEs. If the higher layer parameter dl-DataToUL-ACK-MulticastDciFormat1_0 is not provided, k1 list {1, 2, 3, 4, 5, 6, 7, 8} is applied to multicast DCI format 1_0.
· The size of ‘PDSCH-to-HARQ_feedback timing indicator’ field of multicast DCI format 1_0 is fixed at 3 bits.
R1-2112542 Summary#4 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
R1-2112830 Summary#5 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
From Nov 19th GTW session
Agreement
If locationAndBandwidth-Multicast is not configured in a cfr-Config-Multicast, the default value is the locationAndBandwidth of the DL BWP in which the cfr-Config-Multicast is configured.
Agreement
For applicable PDSCH time domain resource allocation for multicast DCI format,
· if pdsch-TimeDomainAllocationList in PDSCH-Config-Multicast is provided, the pdsch-TimeDomainAllocationList in PDSCH-Config-Multicast is applied,
· else if pdsch-TimeDomainAllocationList in PDSCH-Config-Multicast is not provided but pdsch-TimeDomainAllocationList in PDSCH-ConfigCommon is provided, the pdsch-TimeDomainAllocationList in PDSCH-ConfigCommon is applied,
· else if both pdsch-TimeDomainAllocationList in PDSCH-Config-Multicast and pdsch-TimeDomainAllocationList in PDSCH-ConfigCommon are not provided, Default A table is applied irrespective of the SS/PBCH block and CORESET multiplexing pattern.
Decision: As per email decision posted on Nov 20th,
Agreement
For multicast in RRC_CONNECTED state,
· Only SPS-Config-Multicast(s) configured in CFR for multicast can be activated/deactivated by GC-PDCCH with G-CS-RNTI.
· SPS-Config-Multicast(s) configured in CFR for multicast cannot be activated by unicast PDCCH with CS-RNTI, but can be deactivated by unicast PDCCH with CS-RNTI.
Agreement
For multicast of RRC_CONNECTED UEs in Rel-17,
· DCI format 2_x cannot be configured in the same CSS configuration with multicast DCI formats.
Agreement
For multicast, if a UE is configured with a CFR in the active DL BWP, for timer-based active DL BWP switching to a default BWP, option 1 is supported.
· Option 1: UE also starts or restarts BWP-InactivityTimer when it successfully decodes a GC-PDCCH addressed to group-common RNTI (e.g., G-RNTI or G-CS-RNTI) for multicast on/for the active BWP or when a MAC PDU for is received in a configured downlink assignment for multicast.
o UE does not start or restart BWP-InactivityTimer when it successfully decodes a GC-PDCCH
R1-2112851 LS on multicast reception on SCell for MBS RAN1, CMCC
Decision: No consensus on the content; the LS is withdrawn.
R1-2110778 Mechanisms to improve reliability for RRC_CONNECTED UEs Huawei, HiSilicon, CBN
R1-2110890 Remaining Issues on MBS Reliability FUTUREWEI
R1-2110896 PUCCH formats for NACK-ONLY based HARQ-ACK feedback TD Tech, Chengdu TD Tech
R1-2110911 Discussion on Mechanisms to Improve Reliability for RRC_CONNECTED UEs ZTE
R1-2111040 Remaining issues on mechanisms to improve reliability for RRC_CONNECTED Ues vivo
R1-2111114 Mechanisms to improve MBS reliability for RRC_CONNECTED UEs Spreadtrum Communications
R1-2111136 Reliability Improvements for RRC_CONNECTED UEs Nokia, Nokia Shanghai Bell
R1-2111231 Discussion on reliability improvement mechanism for RRC_CONNECTED UEs in MBS CATT
R1-2111304 UL feedback for RRC-CONNECTED UEs in MBS OPPO
R1-2111472 Discussion on enabling/disabling HARQ-ACK feedback for multicast of RRC_CONNECTED UEs ETRI
R1-2111517 Mechanisms to Improve Reliability of NR-MBS for RRC_CONNECTED UEs Intel Corporation
R1-2111550 Discussion on mechanisms to improve reliability for RRC_CONNECTED UEs Xiaomi
R1-2111628 Discussion on reliability improvement CMCC
R1-2111696 Discussion on Reliability Improvements for RRC_CONNECTED UEs NEC
R1-2111762 On mechanisms to improve reliability for RRC_CONNECTED UEs Samsung
R1-2111898 Discussion on MBS reliability improvement for RRC_CONNECTED UEs Apple
R1-2111985 Discussion on Reliability Enhancement for Simultaneous MBS and Unicast Reception TCL Communication Ltd.
R1-2112064 Mechanisms to improve reliability of Broadcast/Multicast service LG Electronics
R1-2112129 Discussion on HARQ-ACK feedback for multicast for RRC_CONNECTED UEs NTT DOCOMO, INC.
R1-2112162 On reliability improvement for RRC-CONNECTED UEs Lenovo, Motorola Mobility
R1-2112240 Views on UE feedback for Multicast RRC_CONNECTED UEs Qualcomm Incorporated
R1-2112313 Discussion on mechanisms to improve reliability for RRC_CONNECTED UEs MediaTek Inc.
R1-2112347 Mechanisms to improve reliability for RRC_CONNECTED Ues Ericsson
R1-2112383 Discussion on MBS reliability for RRC_CONNECTED UEs Google Inc.
[107-e-NR-MBS-02] – Jinhuan (Huawei)
Email discussion/approval on mechanisms to improve reliability for RRC_CONNECTED UEs with checkpoints for agreements on November 15 and 19
R1-2112456 FL summary#1 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
From Nov 11th GTW session
Agreement
When UE is configured with different codebook types for unicast and multicast and when UE is scheduled to multiplex HARQ-ACK for unicast and HARQ-ACK for multicast with the same priority in the same PUCCH slot,
· UE generates two separate sub-codebooks for unicast and multicast respectively and then concatenates them by appending sub-codebook for multicast to the sub-codebook for unicast.
o Note: The PUCCH resource for transmitting the codebook is based on the last unicast DCI.
o FFS: when Type-3 HARQ-ACK codebook or enhanced Type-2 codebook is used for unicast
o Define a UE capability
Decision: As per email decision posted on Nov 14th,
Agreement
For multicast SPS activation/deactivation, only ACK/NACK based feedback is supported.
R1-2112590 FL summary#2 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
From Nov 15th GTW session
Agreement
UE is not expected to be configured with different PUCCH structures for unicast and multicast for which the HARQ-ACK are with the same priority and to be scheduled to multiplex the HARQ-ACK in the same PUCCH slot simultaneously.
Proposal 2.2.2-1
For the Type-1 codebook construction for FDM-ed unicast and multicast via Opt 4 (from the previous agreement), when UE is configured with multiple G-RNTIs and UE is configured with fdmed-Reception-Multicast, the sub-codebook for multicast consists of the sub-codebooks for each G-RNTI by appending one to another in ascending order of G-RNTI value.
• Note: The maximum numbers of G-RNTI configured to UE is up to UE capability which will be discussed in UE features.
• Note: this applies for at most one unicast PDSCH and one multicast PDSCH in one slot
Agreement
For a UE that supports multicast, the same TDRA table applies to all G-RNTIs if configured on a given serving cell.
Agreement
For a UE that supports multicast, when PUCCH-Config for ACK/NACK based feedback for multicast is configured separately from unicast, the PUCCH-Config is applied to all G-RNTIs with ACK/NACK based feedback with the same priority on a given serving cell.
· Note: The dl-DataToUL-ACK is included in PUCCH-Config
Agreement
At
least for ACK/NACK based feedback, for obtaining a transmission power for a
PUCCH, for Type-2 codebook, 
is determined as follows:
, where
is computed as in
R15/R16.
is the total
number of bits for all configured G-RNTIs.
Decision: As per email decision posted on Nov 16th,
Agreement
· For PTM retransmission,
o if UE is configured to enable/disable HARQ-ACK per group-common DCI indication for initial transmission, whether HARQ-ACK is enabled/disabled for PTM retransmission also follows the indication in the group-common DCI scheduling the PTM retransmission.
o if UE is configured directly whether the HARQ-ACK is enabled/disabled, it applies to both PTM initial transmission and retransmission.
· For PTP retransmission, the HARQ-ACK is always enabled.
Decision: As per email decision posted on Nov 18th,
Agreement
Support enabling/disabling HARQ-ACK for NACK-only based feedback.
· The relevant agreements made for ACK/NACK based feedback can be extended for the support of NACK-only, including:
o RRC signalling configures the presence of the field “enabling/disabling HARQ-ACK feedback indication” in the group-common DCI and the configuration is per G-RNTI.
o RRC signalling configures directly whether the HARQ-ACK feedback is enabled or disabled and the configuration is per G-RNTI.
Agreement
HARQ-ACK feedback option is configured per G-CS-RNTI.
R1-2112591 FL summary#3 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
R1-2112592 FL summary#4 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
From Nov 19th GTW session
Agreement
For group-common DCI indicating whether ACK/NACK based HARQ-ACK feedback is enabled/disabled, the “enabling/disabling HARQ-ACK feedback indication” is included in DCI format 1_1 scrambled by G-RNTI
· For DCI format 1_1 scrambled by G-CS-RNTI, it is discussed separately.
Agreement
For the DCI format including the field of “enabling/disabling HARQ-ACK feedback indication” for multicast scheduling, the field is a new field with 1 bit.
Agreement
For multicast SPS PDSCH without PDCCH scheduling, support the following:
· RRC signalling configures the presence of the field “enabling/disabling HARQ-ACK feedback indication” in the group-common DCI for multicast SPS activation.
o The configuration is per G-CS-RNTI.
o Separate UE capability is needed from that for dynamic scheduling for multicast.
· RRC signalling configures directly whether the HARQ-ACK feedback is enabled or disabled.
o The configuration is per G-CS-RNTI.
Decision: As per email decision posted on Nov 19th,
Agreement
For the Type-1 codebook construction for FDM-ed unicast and multicast via Opt 4 (from the previous agreement), when UE is configured with multiple G-RNTIs and UE is configured with fdmed-Reception-Multicast, the sub-codebook for multicast consists of the sub-codebooks for each G-RNTI by appending one to another in ascending order of G-RNTI value.
· The sub-codebook for each G-RNTI is generated per the k1 and TDRA configurations for the same G-RNTI as the legacy procedure.
· FFS: whether/how to reduce the Type-1 codebook size when multiple G-RNTIs are configured.
· Note: The maximum number of G-RNTI(s) configured to UE for the FDMed unicast and multicast Type-1 codebook is up to UE capability which will be discussed in UE features.
R1-2110779 Discussion on UE receiving broadcast in RRC IDLE/INACTIVE state Huawei, HiSilicon, CBN
R1-2110891 MBS Support for RRC IDLE/INACTIVE UEs FUTUREWEI
R1-2110897 Discussion on basic functions for broadcast mode TD Tech, Chengdu TD Tech
R1-2110912 Discussion on basic Functions for Broadcast or Multicast for RRC_IDLE or RRC_INACTIVE UEs ZTE
R1-2111041 Remaining issues on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE Ues vivo
R1-2111115 Basic Functions for Broadcast or Multicast for RRC_IDLE or RRC_INACTIVE UEs Spreadtrum Communications
R1-2111137 Basic Functions for Broadcast / Multicast for RRC_IDLE / RRC_INACTIVE UEs Nokia, Nokia Shanghai Bell
R1-2111232 Discussion on basic functions for broadcast multicast for RRC_IDLE RRC_INACTIVE UEs CATT
R1-2111305 Discussion on basic functions for RRC_IDLE/RRC_INACTIVE UEs OPPO
R1-2111408 Considerations on MBS functions for RRC_IDLE/INACTIVE UEs Sony
R1-2111518 NR-MBS for RRC_IDLE/INACTIVE UEs Intel Corporation
R1-2111551 Discussion on basic functions for broadcast/multicast for RRC_IDLERRC_INACTIVE UEs Xiaomi
R1-2111629 Discussion on NR MBS in RRC_IDLE/ RRC_INACTIVE states CMCC
R1-2111763 On basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs Samsung
R1-2111899 Discussion on MBS for RRC_IDLE and RRC_INACTIVE UEs Apple
R1-2112065 Basic function for broadcast/multicast LG Electronics
R1-2112082 Discussion on basic functions for broadcast or multicast for RRC_IDLE and RRC_INACTIVE UEs ASUSTeK
R1-2112130 Discussion on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs NTT DOCOMO, INC.
R1-2112163 Basic functions for broadcast/multicast in idle/inactive states Lenovo, Motorola Mobility
R1-2112241 Views on group scheduling for Broadcast RRC_IDLE/INACTIVE UEs Qualcomm Incorporated
R1-2112314 Discussion on MBS for RRC_IDLE and INACTIVE UEs MediaTek Inc.
R1-2112348 Support for NR multicast reception in RRC Inactive/Idle Ericsson
[107-e-NR-MBS-03] – David (BBC)
Email discussion/approval on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs with checkpoints for agreements on November 15 and 19
R1-2112464 Feature Lead summary #1 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/RRC_INACTIVE states Moderator (BBC)
From Nov 11th GTW session
Agreement
Confirm the working assumption made at RAN1#106bis-e:
Alt 2 (from previous agreement) is supported for broadcast reception with RRC_IDLE/RRC_INACTIVE UEs for the notification of MCCH configuration changes.
· Send an LS to RAN2 with the mechanism agreed in RAN1
Decision: As per email decision posted on Nov 14th,
Agreement
For GC-PDSCH scheduled with DCI format 1_0 for broadcast reception, RB numbering starts from the lowest RB of the CFR.
Conclusion
For broadcast reception, the DCI 1_0 format for GC-PDCCH scheduling a GC-PDSCH does not include the field TB scaling.
R1-2112465 Feature Lead summary #2 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/RRC_INACTIVE states Moderator (BBC)
From Nov 15th GTW session
Agreement
For broadcast reception, the following options is supported for VRB-to-PRB mapping field in the DCI format 1_0 for GC-PDCCH scheduling a GC-PDSCH
Working assumption
For FDRA determination of the DCI format 1_0 for GC-PDCCH for broadcast reception:
is
the size of CORESET 0 if CORESET 0 is configured for the cell; and the
size of initial DL bandwidth part if CORESET 0 is not configured for the
cell.
) is larger than the size of
CORESET0/initial
DL bandwidth part,
the resource indication value (RIV) is defined as in section
5.1.2.2.2 in TS38.214, where
K is the
maximum value from set {1, 2, 4, 6, 8, 10, 12} which satisfies 
;otherwise, 
Agreement
For broadcast reception with RRC_IDLE/RRC_INACTIVE UEs:
R1-2112466 Feature Lead summary #3 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/RRC_INACTIVE states Moderator (BBC)
From Nov 17th GTW session
Agreement
Adding the following PDSCH TDRA table determination rule for broadcast to Table 5.1.2.1.1-1 of TS38.214.
|
RNTI |
PDCCH search space |
SS/PBCH block and CORESET multiplexing pattern |
pdsch-ConfigCommon includes pdsch-TimeDomainAllocationList |
pdsch-Config includes pdsch-TimeDomainAllocationList |
pdsch-Config-broadcast includes pdsch-TimeDomainAllocationList |
PDSCH time domain resource allocation to apply |
|
MCCH_RNTI, G_RNTI for broadcast |
Type-x Common for broadcast |
1 |
No |
- |
- |
Default A |
|
2 |
No |
- |
- |
Default B |
||
|
3 |
No |
- |
- |
Default C |
||
|
|
|
|
|
|
||
|
1,2,3 |
Yes |
- |
No |
pdsch-TimeDomainAllocationList provided in pdsch-ConfigCommon |
||
|
1,2,3 |
No/Yes |
- |
Yes |
pdsch-TimeDomainAllocationList provided in pdsch-Config-broadcast |
Agreement
The definition of the broadcast CFR frequency resources reuses the legacy definition of BWP frequency resources for unicast using the combination of Point A, offsetToCarrier and locationAndBandwidth to indicate the exact location of the CFR with respect to the carrier starting RB.
· Note: for Case A and Case C, the above parameters (Point A, offsetToCarrier and locationAndBandwidth) can be derived from the configurations in MIB and SIB1, respectively.
Decision: As per email decision posted on Nov 18th,
Agreement
For RRC_IDLE/INACTIVE UEs, for slot-level repetition for MTCH, support:
· (Config A) UE can be configured with pdsch-AggregationFactor per G-RNTI, applied to DCI format 1_0 with the G-RNTI.
· (Config B) UE can be configured with TDRA table with repetitionNumber as part of the TDRA table in PDSCH-Config-Broadcast
· If UE is configured with Config B, UE does not expect to be configured with Config A for the same GC-PDSCH.
Agreement
The following agreements for RRC_CONECTED UEs also apply for broadcast reception with UEs in RRC_IDLE/ RRC_INACTIVE states, with the following updates:
Agreement:
For LBRM and TBS determination for GC-PDSCH:
· The maximum number of layers can be provided by maxMIMO-Layers in PDSCH-Config for MBS in CFR; if not provided, a default value is defined.
o FFS the default value.
· The maximum modulation order can be determined from mcs-Table in PDSCH-Config for MBS in CFR;
o FFS: if mcs-Table in PDSCH-Config for MBS is not configured in CFR, a value determined from mcs-Table in PDSCH-Config for unicast in the active DL BWP is used; if the mcs-Table in PDSCH-Config for unicast is not configured, Table 5.1.3.1-1 in TS38.214 is used (similar as the default value in R16).
· xOverhead can be provided in PDSCH-Config for MBS in CFR; if not provided, a default value of zero is used.
· The number of PRBs is determined based on the size of CFR.
Agreement:
For LBRM and TBS determination for GC-PDSCH, the default value of the maximum number of layers is 1 if maxMIMO-Layers in PDSCH-Config for MBS in CFR is not configured.
Agreement:
For determination of maximum modulation order for LBRM and TBS determination for GC-PDSCH,
· if mcs-Table in PDSCH-Config for MBS is not configured in CFR, Table 5.1.3.1-1 in TS38.214 is used (similar as the default value in R16).
For LBRM and TBS determination for GC-PDSCH for broadcast reception:
· the maximum number of layers is 1
· the maximum modulation order can be determined from mcs-Table in PDSCH-Config for broadcast.
· If mcs-Table in PDSCH-Config is not configured in CFR for broadcast, Table 5.1.3.1-1 in TS38.214 is used.
R1-2112645 DRAFT Reply LS on MCCH change notification Moderator (BBC)
Decision: As per email decision posted on Nov 18th, the draft LS is endorsed. Final LS is approved in R1-2112646.
R1-2112467 Feature Lead summary #4 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/RRC_INACTIVE states Moderator (BBC)
From Nov 19th GTW session
Agreement
Confirm the following working assumption with the following note:
· Note: Confirming this WA does not have impact on the down-selection decision for CFR cases
Working assumption
For FDRA determination of the DCI format 1_0 for GC-PDCCH for broadcast reception:
·
is the
size of CORESET 0 if CORESET 0 is configured for the
cell; and the size of initial DL bandwidth part if CORESET 0 is not configured
for the cell.
·
If the size of CFR (i.e. ) is
larger than the size of CORESET0/initial DL bandwidth part,
the resource indication value (RIV) is defined as in section 5.1.2.2.2
in TS38.214, where K is the maximum value from set {1, 2, 4, 6, 8, 10,
12} which satisfies ;otherwise,
Conclusion
RAN1 cannot get consensus on the support of Case D and/or Case E.
Decision: As per email decision posted on Nov 19th,
Conclusion
Is up to RAN2 decision:
· the configuration of the MTCH scheduling window parameters: monitoring periodicity and the starting of the periodicity:
· whether the MTCH scheduling window is associated to one or multiple or all G-RNTIs
· Send an LS to RAN2 to inform about RAN1 conclusion
R1-2112850 LS on MTCH scheduling window RAN1, BBC
Decision: As per email decision posted on Nov 20th, the LS is approved.
Final summary in R1-2112715.
R1-2110898 Discussion on typical configuration for NR MBS CHENGDU TD TECH LTD.
R1-2110913 Consideration on potential further enhancement for MBS ZTE
R1-2111042 Other issues for Rel-17 MBS vivo
R1-2111138 Other Aspects for Rel-17 MBS Nokia, Nokia Shanghai Bell
R1-2111233 Discussion on other issues in Rel-17 MBS CATT
R1-2111552 Discussion on remaining issues for idle and inactive UE Xiaomi
R1-2111917 Discussion on RRC parameters for NR MBS Huawei, HiSilicon, CBN
R1-2112066 Other aspects for MBS LG Electronics
R1-2112085 Discussion on further improvements for MBS ASUSTeK
R1-2112349 Assumptions for performance evaluations of NR-MBS Ericsson
Please refer to RP-201038 for detailed scope of the WI. Please also refer to slide 6 of R1-2200001 for additional guidance for this e-meeting. Relevant incoming LSs in R1-2200009.
R1-2200795 Session notes for 8.12 (NR Multicast and Broadcast Services) Ad-Hoc Chair (Huawei)
[107bis-e-R17-RRC-MBS] – Fei (CMCC)
Email discussion on Rel-17 RRC parameters for NR MBS
- Email discussion to start on January 20 and end by January 25
R1-2200797 Summary of email discussion on Rel-17 RRC parameters for NR MBS Moderator (CMCC, Huawei, Qualcomm)
Document is noted. For consolidation under 8 in [107bis-e-R17-RRC].
R1-2200810 Agreements for NR MBS up to RAN1#107bis Rapporteur (CMCC)
R1-2200027 Resource configuration and group scheduling for RRC_CONNECTED UEs Huawei, HiSilicon, CBN
R1-2200094 Remaining issues on mechanisms to support group scheduling for RRC_CONNECTED Ues vivo
R1-2200117 Discussion on Mechanisms to Support Group Scheduling for RRC_CONNECTED UEs ZTE
R1-2200681 Remaining issues on group scheduling mechanism for RRC_CONNECTED UEs in MBS CATT, CBN (rev of R1-2200133)
R1-2200157 Remaining Issues on Group Scheduling Mechanisms for RRC_CONNECTED Ues supporting MBS Nokia, Nokia Shanghai Bell
R1-2200213 Remaining issues on group scheduling for RRC_CONNECTED UEs Samsung
R1-2200243 Remaining issues on group scheduling mechanisms for RRC_CONNECTED UEs NTT DOCOMO, INC.
R1-2200283 Discussion on the remaining issues on MBS group scheduling for RRC_CONNETED UEs Spreadtrum Communications
R1-2200308 Maintenance on group scheduling for Multicast RRC_CONNECTED UEs Qualcomm Incorporated
R1-2200350 Discussion on remaining issues of group Scheduling mechanism for RRC_CONNECTED UEs OPPO
R1-2200386 Group Scheduling for RRC_CONNECTED Ues Intel Corporation
R1-2200427 Discussion on group scheduling mechanism for RRC_CONNECTED UEs Apple
R1-2200451 Discussion on mechanisms to support group scheduling for RRC_CONNECTED UEs xiaomi
R1-2200471 On group scheduling mechanism for RRC_CONNECTED UEs Lenovo, Motorola Mobility
R1-2200512 Remaining Issues on Group Scheduling Mechanisms for RRC_CONNECTED UEs NEC
R1-2200525 Further discussion on group scheduling for multicast mode TD Tech, Chengdu TD Tech
R1-2200529 Maintenance on mechanisms to support group scheduling for RRC_CONNECTED UEs ETRI
R1-2200549 Remaining issues on NR MBS group scheduling for RRC_CONNECTED UEs MediaTek Inc.
R1-2200578 Support of group scheduling for RRC_CONNECTED UEs LG Electronics
R1-2200596 Remaining issues on group scheduling mechanisms for RRC_CONNECTED UEs CMCC
R1-2200616 Discussion on mechanisms to support group scheduling for RRC_CONNECTED UEs ASUSTeK
R1-2200665 Mechanisms to support MBS group scheduling for RRC_CONNECTED UEs Ericsson
R1-2200670 Corrections of MBS for RRC_CONNECTED UEs Google Inc.
[107bis-e-R17-MBS-01] – Fei (CMCC)
Email discussion/approval on mechanisms to support group scheduling for RRC_CONNECTED UEs
- 1st check point: January 20
- Final check point: January 25
R1-2200595 Summary#1 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
From Jan 18th GTW session
Agreement
DCI format 4_2 doesn’t include the following fields:
· Scell dormancy indication
· BWP indicator
DCI format 4_2 includes the following field (configurable):
· MCS/NDI/RV for TB2
· Support of this field is subject to UE capability
Agreement
DCI format 4_2 includes ‘ZP CSI-RS trigger’ field.
Agreement
For DCI size alignment of DCI format 4_2, the size of DCI format 4_2 is configured by RRC signaling for RRC_CONNECTED UEs (similar as the configuration for the size alignment among DCI format 2_0/2_1/2_4/2_5/2_6).
Conclusion
For multicast of RRC_CONNECTED UEs, the value range of sps-ConfigIndex in SPS-Config-Multicast is {0-7}, and sps-ConfigIndex in sps-Config and SPS-Config-Multicast cannot be configured with the same value.
R1-2200731 Summary#2 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
R1-2200732 Summary#3 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
Decision: As per email decision posted on Jan 21st,
Agreement
The TP below for Clause 10.1 in TS 38.213v17.0.0 is endorsed.
----------------- Start of TP ----------------
10.1 UE procedure for determining physical downlink control channel assignment
<Unchanged text is omitted>
A
UE does not expect to detect, in a same PDCCH monitoring occasion, a DCI format
with CRC scrambled by a SI-RNTI, RA-RNTI, MsgB-RNTI, TC-RNTI, P-RNTI, C-RNTI, CS-RNTI, or MCS-RNTI, MCCH-RNTI,
G-RNTI, or G-CS-RNTI and a DCI format with CRC scrambled by a SL-RNTI or a
SL-CS-RNTI for scheduling respective PDSCH reception and PSSCH transmission on
a same serving cell.
<Unchanged text is omitted>
----------------- End of TP ----------------
Agreement
The TP below for Clause 5.1.2.2 in TS 38.214v17.0.0 is endorsed.
----------------- Start of TP ----------------
5.1.2.2 Resource allocation in frequency domain
<Unchanged text is omitted>
Two downlink resource allocation schemes, type 0 and type 1, are supported. The UE shall assume that when the scheduling grant is received with DCI format 1_0, DCI format 4_0 or DCI format 4_1, then downlink resource allocation type 1 is used.
If the scheduling DCI is configured to indicate the downlink resource allocation type as part of the 'Frequency domain resource assignment' field by setting a higher layer parameter resourceAllocation in PDSCH-Config to 'dynamicSwitch', for DCI format 1_1 or setting a higher layer parameter resourceAllocationDCI-1-2 in PDSCH-Config to 'dynamicSwitch' for DCI format 1_2 or setting a higher layer parameter resourceAllocation in PDSCH-Config-Multicast to 'dynamicSwitch' for DCI format 4_2, the UE shall use downlink resource allocation type 0 or type 1 as defined by this DCI field. Otherwise the UE shall use the downlink frequency resource allocation type as defined by the higher layer parameter resourceAllocation in PDSCH-Config for DCI format 1_1 or by the higher layer parameter resourceAllocationDCI-1-2 for DCI format 1_2 or by the higher layer parameter resourceAllocation in PDSCH-Config-Multicast for DCI format 4_2.
<Unchanged text is omitted>
----------------- End of TP ----------------
Agreement
The TP below for Clause 5.1.2.3 in TS 38.214v17.0.0 is endorsed.
----------------- Start of TP ----------------
<Unchanged text is omitted>
The PRB bundling procedures for PDSCH scheduled by PDCCH with DCI format 1_1 described in this clause equally apply to PDSCH scheduled by PDCCH with DCI format 1_2, by applying the parameters of prb-BundlingTypeDCI-1-2 instead of prb-BundlingType as well as vrb-ToPRB-InterleaverDCI-1-2 instead of vrb-ToPRB-Interleaver. The PRB bundling procedures for PDSCH scheduled by PDCCH with DCI format 1_1 described in this clause equally apply to PDSCH scheduled by PDCCH with DCI format 4_2, by applying the parameters of prb-BundlingType given by PDSCH-Config-Multicast as well as vrb-ToPRB-Interleaver given by PDSCH-Config-Multicast.
A UE may
assume that precoding granularity is 
consecutive
resource blocks in the frequency domain. can
be equal to one of the values among {2, 4, wideband}.
If is
determined as "wideband", the UE is not expected to be scheduled with
non-contiguous PRBs and the UE may assume that the same precoding is applied to
the allocated resource associated with a same TCI state or a same QCL
assumption.
<Unchanged text is omitted>
----------------- End of TP ----------------
Agreement
For DMRS of GC-PDSCH,
· For GC-PDSCH scheduled by a DCI format 4_0/4_1, the UE assumes dmrs-AdditionalPosition = ‘pos2’, similar as that of DCI format 1_0.
· For GC-PDSCH scheduled by a DCI format 4_2, the UE assumes dmrs-AdditionalPosition in DMRS-Config if configured in PDSCH-Config-Multicast, similar as that of DCI format 1_1.
· Adopt the following TP for Clause 5.1.6.2 in TS 38.214:
----------------- Start of TP ----------------
5.1.6.2 DM-RS reception procedure
<Unchanged text is omitted>
The DM-RS reception procedures for PDSCH scheduled by PDCCH with DCI format 1_1 described in this clause equally apply to PDSCH scheduled by PDCCH with DCI format 1_2, by applying the parameters of dmrs-DownlinkForPDSCH-MappingTypeA-DCI-1-2 and dmrs-DownlinkForPDSCH-MappingTypeB-DCI-1-2 instead of dmrs-DownlinkForPDSCH-MappingTypeA and dmrs-DownlinkForPDSCH-MappingTypeB.
The DM-RS reception procedures for PDSCH scheduled by PDCCH with DCI format 1_1 described in this clause equally apply to PDSCH scheduled by PDCCH with DCI format 4_2, by applying the parameters of dmrs-DownlinkForPDSCH-MappingTypeA and dmrs-DownlinkForPDSCH-MappingTypeB in PDSCH-Config-Multicast instead of dmrs-DownlinkForPDSCH-MappingTypeA and dmrs-DownlinkForPDSCH-MappingTypeB in PDSCH-Config.
When receiving PDSCH scheduled by DCI format 1_0, 4_0, 4_1 or receiving PDSCH before dedicated higher layer configuration of any of the parameters dmrs-AdditionalPosition, maxLength and dmrs-Type, the UE shall assume that the PDSCH is not present in any symbol carrying DM-RS except for PDSCH with allocation duration of 2 symbols with PDSCH mapping type B (described in clause 7.4.1.1.2 of [4, TS 38.211]), and a single symbol front-loaded DM-RS of configuration type 1 on DM-RS port 1000 is transmitted, and that all the remaining orthogonal antenna ports are not associated with transmission of PDSCH to another UE and in addition
- For PDSCH with mapping type A and type B, the UE shall assume dmrs-AdditionalPosition='pos2' and up to two additional single-symbol DM-RS present in a slot according to the PDSCH duration indicated in the DCI as defined in Clause 7.4.1.1 of [4, TS 38.211], and
- For PDSCH with allocation duration of 2 symbols with mapping type B, the UE shall assume that the PDSCH is present in the symbol carrying DM-RS.
When receiving PDSCH scheduled by DCI format 1_1 by PDCCH with CRC scrambled by C-RNTI, MCS-C-RNTI, or CS-RNTI or DCI format 4_2 by PDCCH with CRC scrambled by G-RNTI or G-CS-RNTI,
- the UE may be configured with the higher layer parameter dmrs-Type, and the configured DM-RS configuration type is used for receiving PDSCH in as defined in Clause 7.4.1.1 of [4, TS 38.211].
- the UE may be configured with the maximum number of front-loaded DM-RS symbols for PDSCH by higher layer parameter maxLength given by DMRS-DownlinkConfig.
- if maxLength is set to 'len1', single-symbol DM-RS can be scheduled for the UE by DCI, and the UE can be configured with a number of additional DM-RS for PDSCH by higher layer parameter dmrs-AdditionalPosition, which can be set to 'pos0', 'pos1', 'pos2' or 'pos3'.
- if maxLength is set to 'len2', both single-symbol DM-RS and double symbol DM-RS can be scheduled for the UE by DCI, and the UE can be configured with a number of additional DM-RS for PDSCH by higher layer parameter dmrs-AdditionalPosition, which can be set to 'pos0' or 'pos1'.
- and the UE shall assume to receive additional DM-RS as specified in Table 7.4.1.1.2-3 and Table 7.4.1.1.2-4 as described in Clause 7.4.1.1.2 of [4, TS 38.211].
<Unchanged text is omitted>
When receiving PDSCH scheduled by DCI format 1_0, 4_0, 4_1, the UE shall assume the number of DM-RS CDM groups without data is 1 which corresponds to CDM group 0 for the case of PDSCH with allocation duration of 2 symbols, and the UE shall assume that the number of DM-RS CDM groups without data is 2 which corresponds to CDM group {0,1} for all other cases.
<Unchanged text is omitted>
----------------- End of TP ----------------
Agreement
For PDSCH scheduled by a DCI format 4_1/4_2, the UE assumes phaseTrackingRS in dmrs-DownlinkForPDSCH-MappingTypeA or dmrs-DownlinkForPDSCH-MappingTypeB configured in PDSCH-Config-Multicast.
· Adopt the following TP for Clause 5.1.6.3 in TS 38.214:
----------------- Start of TP ----------------
5.1.6.3 PT-RS reception procedure
<Unchanged text is omitted>
The procedures on PT-RS reception described in this clause apply to a UE receiving PDSCH scheduled by DCI format 1_2 configured with the higher layer parameter phaseTrackingRS in dmrs-DownlinkForPDSCH-MappingTypeA-DCI-1-2 or dmrs-DownlinkForPDSCH-MappingTypeB-DCI-1-2 and to a UE receiving PDSCH scheduled by DCI format 1_0 or DCI format 1_1 configured with the higher layer parameter phaseTrackingRS in dmrs-DownlinkForPDSCH-MappingTypeA or dmrs-DownlinkForPDSCH-MappingTypeB. The procedures on PT-RS reception described in this clause apply to a UE receiving PDSCH scheduled by DCI format 4_1 or DCI format 4_2 configured with the higher layer parameter phaseTrackingRS in dmrs-DownlinkForPDSCH-MappingTypeA or dmrs-DownlinkForPDSCH-MappingTypeB in PDSCH-Config-Multicast.
<Unchanged text is omitted>
----------------- End of TP ----------------
Agreement
The TP below for Clause 5.1 in TS 38.214v17.0.0 is endorsed.
----------------- Start of TP ----------------
5.1 UE procedure for receiving the physical downlink shared channel
<Unchanged text is omitted>
A
UE shall upon detection of a PDCCH with a configured DCI format 1_0, 1_1, 4_0, 4_1, 4_2 or 1_2 decode the corresponding PDSCHs
as indicated by that DCI. For any HARQ process ID(s) in a given scheduled cell,
the UE is not expected to receive a PDSCH that overlaps in time with another
PDSCH. The UE is not expected to receive another PDSCH for a given HARQ process
until after the end of the expected transmission of HARQ-ACK for that HARQ
process, where the timing is given by Clause 9.2.3 of [6]. Except for the case
when a UE is configured by higher layer parameter PDCCH-Config that
contains two different values of coresetPoolIndex in ControlResourceSet
and PDCCHs that schedule two PDSCHs are associated to different ControlResourceSets
having different values of coresetPoolIndex, in a given scheduled cell,
the UE is not expected to receive a first PDSCH and a second PDSCH, starting
later than the first PDSCH, with its corresponding HARQ-ACK assigned to be
transmitted on a resource ending before the start of a different resource for
the HARQ-ACK assigned to be transmitted for the first PDSCH, where the two
resources are in different slots for the associated HARQ-ACK transmissions,
each slot is composed of 
symbols [4] or a number
of symbols indicated by subslotLengthForPUCCH if provided, and the
HARQ-ACK for the two PDSCHs are associated with the HARQ-ACK codebook of the
same priority. Except for the case when a UE is configured by higher layer
parameter PDCCH-Config that contains two different values of coresetPoolIndex
in ControlResourceSet and PDCCHs that schedule two PDSCHs are associated
to different ControlResourceSets having different values of coresetPoolIndex,
in a given scheduled cell, the UE is not expected to receive a first PDSCH, and
a second PDSCH, starting later than the first PDSCH, with its corresponding
HARQ-ACK assigned to be transmitted on a resource ending before the start of a
different resource for the HARQ-ACK assigned to be transmitted for the first
PDSCH if the HARQ-ACK for the two PDSCHs are associated with HARQ-ACK codebooks
of different priorities. For any two HARQ process IDs in a given scheduled
cell, if the UE is scheduled to start receiving a first PDSCH starting in
symbol j by a PDCCH ending in symbol i, the UE is not expected to
be scheduled to receive a PDSCH starting earlier than the end of the first
PDSCH with a PDCCH that ends later than symbol i. In a given scheduled
cell, for any PDSCH corresponding to SI-RNTI, the UE is not expected to decode
a re-transmission of an earlier PDSCH with a starting symbol less than N
symbols after the last symbol of that PDSCH, where the value of N
depends on the PDSCH subcarrier spacing configuration m, with N=13
for m=0, N=13 for m=1, N=20 for m=2, and N=24
for m=3.
<Unchanged text is omitted>
----------------- End of TP ----------------
Agreement
The TP below for Clause 5.1.3.2 in TS 38.214v17.0.0 is endorsed.
----------------- Start of TP ----------------
5.1.3.2 Transport block size determination
<Unchanged text is omitted>
In case the higher layer parameter maxNrofCodeWordsScheduledByDCI indicates that two codeword transmission is enabled, then one of the two transport blocks is disabled by DCI format 1_1 if IMCS = 26 and if rvid = 1 for the corresponding transport block. If both transport blocks are enabled, transport block 1 and 2 are mapped to codeword 0 and 1 respectively. If only one transport block is enabled, then the enabled transport block is always mapped to the first codeword.
For
the PDSCH assigned by a PDCCH with DCI format 1_0,
format 1_1, format 4_0, format 4_1,
format 4_2 or format 1_2 with CRC scrambled by C-RNTI, MCS-C-RNTI, TC-RNTI,
CS-RNTI, G-RNTI, G-CS-RNTI or SI-RNTI, if Table 5.1.3.1-2 is used and 
QUOTE
0
≤ 
, or a table other than
Table 5.1.3.1-2 is used and QUOTE
0 ≤ , the UE shall, except if
the transport block is disabled in DCI format 1_1, first determine the TBS as specified below:
<Unchanged text is omitted>
----------------- End of TP ----------------
Agreement
The TP below for Clause 7.3.1.6 in TS 38.211v17.0.0 is endorsed.
----------------- Start of TP ----------------
7.3.1.6 Mapping from virtual to physical resource blocks
<Unchanged text is omitted>
-
for PDSCH transmissions scheduled with DCI
format 1_0 in any common search space in bandwidth part 
with
starting position 
, other than
Type0-PDCCH common search space in CORESET 0 and
common search space associated with G-RNTI or G-CS-RNTI, the set of 
virtual
resource blocks 
, where 
is the
size of CORESET 0 if CORESET 0 is configured for the cell and the size of
initial downlink bandwidth part if CORESET 0 is not configured for the cell,
are divided into 
virtual
resource-block bundles in increasing order of the virtual resource-block number
and virtual bundle number and the set of 
physical
resource blocks 
are
divided into physical
resource-block bundles in increasing order of the physical resource-block
number and physical bundle number, where 
, 
is the
bundle size, and 
is the
lowest-numbered physical resource block in the control resource set where the
corresponding DCI was received.
<Unchanged text is omitted>
----------------- End of TP ----------------
Agreement
The TP below for Clause 5.1.3.1 in TS 38.214v17.0.0 is endorsed.
----------------- Start of TP ----------------
<Unchanged text is omitted>
elseif the higher layer parameter mcs-Table given by PDSCH-Config-Multicast is set to 'qam256', and the PDSCH is scheduled by a PDCCH with DCI format 4_1 or 4_2 with CRC scrambled by G-RNTI
- the UE shall use IMCS and Table 5.1.3.1-2 to determine the modulation order (Qm) and Target code rate (R) used in the physical downlink shared channel.
elseif the higher layer parameter mcs-Table given by PDSCH-Config-Multicast is set to 'qam64LowSE', and the PDSCH is scheduled by a PDCCH with DCI format 4_1 or 4_2 with CRC scrambled by G-RNTI
- the UE shall use IMCS and Table 5.1.3.1-3 to determine the modulation order (Qm) and Target code rate (R) used in the physical downlink shared channel.
<Unchanged text is omitted>
----------------- End of TP ----------------
Agreement
For RRC_CONNECTED UEs receiving broadcast MCCH/MTCH, the Type0B-PDCCH CSS set configured by searchSpace-Broadcast in pdcch-Config-MCCH/pdcch-Config-MTCH follows the same prioritization rule for search space set overbooking procedure as CSS set(s) configured by searchSpace-Multicast.
Agreement
Regarding the number of DCIs that a UE can process in a slot or span, multicast DCI is treated as unicast DCI scheduling DL following the current feature group 3-1/3-5a/3-5b.
Agreement
For multicast RRC_CONNECTED UEs, rateMatchPatternToAddModList, rateMatchPatternGroup1 and rateMatchPatternGroup2 can be configured in PDSCH-Config-Multicast for GC-PDSCH rate matching, subject to UE capability. For PDSCH resource mapping with RB symbol level granularity,
· The procedure for PDSCH scheduled by PDCCH with DCI format 4_1 is similar as that of DCI format 1_0 and the procedure for PDSCH scheduled by PDCCH with DCI format 4_2 is similar as that of DCI format 1_1, by applying the parameters of rateMatchPatternToAddModList, rateMatchPatternGroup1 and rateMatchPatternGroup2 configured in PDSCH-Config-Multicast.
· rateMatchPatternToAddModList, rateMatchPatternGroup1 and rateMatchPatternGroup2 configured in PDSCH-Config for unicast do not apply for GC-PDSCHs.
· rateMatchPatternToAddModList, rateMatchPatternGroup1 and rateMatchPatternGroup2 configured in PDSCH-Config-Multicast for multicast do not apply for unicast PDSCHs.
R1-2200733 Summary#4 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
From Jan 24th GTW session
Agreement
PDSCH processing capability 2 is not applied to PDSCH scheduled by PDCCH with DCI format 4_0/4_1/4_2.
Agreement
Regarding the size of DCI format 4_2 for multicast of RRC_CONNECTED UE,
· the size is configured per CFR for all G-RNTIs (included in cfr-Config-Multicast).
· the value range of the size is {[1]..140} (the same as for DCI format 2_6)
Decision: As per email decision posted on Jan 25th,
Agreement (that resolves the [] on the lower range of the values from Jan 24th agreement)
Regarding the size of DCI format 4_2 for multicast of RRC_CONNECTED UE,
· the value range of the size is {20..140}
Agreement
The TP below for Clause 5.1.4.1 in TS 38.214v17.0.0 is endorsed.
----------------- Start of TP ----------------
5.1.4.1 PDSCH resource mapping with RB symbol level granularity
<Unchanged text is omitted>
The procedures for PDSCH scheduled by PDCCH with DCI format 1_1 described in this clause equally apply to PDSCH scheduled by PDCCH with DCI format 1_2, by applying the parameters of rateMatchPatternGroup1DCI-1-2, rateMatchPatternGroup2DCI-1-2 instead of rateMatchPatternGroup1 and rateMatchPatternGroup2.
The procedures for PDSCH scheduled by PDCCH with DCI format 1_0 described in this clause equally apply to PDSCH scheduled by PDCCH with DCI format 4_1, and the procedures for PDSCH scheduled by DCI format 1_1 described in this clause equally apply to PDSCH scheduled by PDCCH with DCI format 4_2 by applying the parameters of rateMatchPatternToAddModList, rateMatchPatternGroup1 and rateMatchPatternGroup2 configured in PDSCH-Config-Multicast.
<Unchanged text is omitted>
----------------- End of TP ----------------
Agreement
The TP below for Clause 5.1.4.2 in TS 38.214v17.0.0 is endorsed.
----------------- Start of TP ----------------
5.1.4.2 PDSCH resource mapping with RE level granularity
The procedures for PDSCH scheduled by PDCCH with DCI format 1_1 described in this clause equally apply to PDSCH scheduled by PDCCH with DCI format 1_2, by applying the parameters of aperiodicZP-CSI-RS-ResourceSetsToAddModListDCI-1-2 instead of aperiodic-ZP-CSI-RS-ResourceSetsToAddModList. The procedures for PDSCH scheduled by PDCCH with DCI format 1_1 described in this clause equally apply to PDSCH scheduled by PDCCH with DCI format 4_2, by applying the parameters of aperiodicZP-CSI-RS-ResourceSetsToAddModList in PDSCH-Config-Multicast instead of aperiodic-ZP-CSI-RS-ResourceSetsToAddModList in PDSCH-Config.
<Unchanged text is omitted>
----------------- End of TP ----------------
Final summary in R1-2200784.
[107bis-e-R17-MBS-04] – Jinhuan (Huawei)
Email discussion on feasibility check of MBS broadcast reception on SCell and non-serving cell by January 25, for response to :
R1-2200009 LS on MBS broadcast reception on SCell and non-serving cell RAN2, Huawei
R1-2200740 FL summary#1 on MBS broadcast reception on SCell and non-serving cell Moderator (Huawei)
R1-2200769 FL summary#2 on MBS broadcast reception on SCell and non-serving cell Moderator (Huawei)
From Jan 24th GTW session
Agreement
From RAN1 perspective, it is feasible for UE in RRC_CONNECTED state to receive MBS broadcast on an activated SCell as long as UE has capability of supporting MBS broadcast on SCell. From RAN1 perspective, if a UE is to receive MBS broadcast on SCell,
· The capability of supporting MBS broadcast on SCell is separate capability from the one of CA for unicast.
· The UE is not required to monitor DCI formats associated with SI-RNTI, P-RNTI, RA-RNTI in SCell.
· Overbooking for SCell is not supported.
· MBS broadcast reception on SCell can be supported only for RRC_CONNECTED UEs only with self-scheduling.
· Type0-PDCCH CSS set is only configured on the primary cell of the MCG.
· Configuring the search space on SCell for PDCCH monitoring of MBS DCI formats is via unicast RRC signaling.
· The UE capability is expected to be defined by RAN2.
o E.g. the total number of component carriers for receiving broadcast on SCell may be subject to UE capability
· The UE is not required to receive broadcast on PCell and SCell simultaneously
Agreement
From RAN1 perspective, it is feasible for UE in RRC_CONNECTED state to receive MBS broadcast on non-serving cell, which is up to UE implementation and transparent to the network.
· It is assumed in RAN1 that UE receiving MBS broadcast on non-serving cell does not have any impact to operation on serving cell(s), e.g., does not require UE to obtain the related configuration from the serving cell, does not require the network to guarantee the scheduling doesn’t exceed UE’s capability on serving cell, etc.
· RAN1 assumes that receiving MBS broadcast on non-serving cell could be on the same or on a different band, but on a different carrier frequency than a UE’s serving cell
· No RAN1 spec impact and no optimization is pursued in Rel-17 for MBS broadcast reception on non-serving cell.
· The UE capability(ies), if any, is(are) expected to be defined by RAN2.
R1-2200785 DRAFT LS reply to MBS broadcast reception on SCell and non-serving cell Moderator (Huawei)
Decision: As per email decision posted on Jan 25th, the draft LS is endorsed. Final LS to RAN2 is approved in R1-2200798.
R1-2200028 Mechanisms to improve reliability for RRC_CONNECTED UEs Huawei, HiSilicon, CBN
R1-2200095 Remaining issues on mechanisms to improve reliability for RRC_CONNECTED UEs vivo
R1-2200118 Discussion on Mechanisms to Improve Reliability for RRC_CONNECTED UEs ZTE
R1-2200682 Remaining issues on reliability improvement mechanism for RRC_CONNECTED UEs in MBS CATT, CBN (rev of R1-2200134)
R1-2200158 Remaining Issues on Reliability Improvements for RRC_CONNECTED UEs supporting MBS Nokia, Nokia Shanghai Bell
R1-2200214 Remaining issues on mechanisms to improve reliability Samsung
R1-2200244 Remaining details on HARQ-ACK feedback procedure for multicast NTT DOCOMO, INC.
R1-2200284 Discussion on the remaining issues on mechanisms to improve MBS reliability for RRC_CONNECTED UEs Spreadtrum Communications
R1-2200309 Maintenance on UE feedback for Multicast RRC_CONNECTED UEs Qualcomm Incorporated
R1-2200351 Remaining issues on UL feedback for MBS of RRC-CONNECTED UEs OPPO
R1-2200387 Reliability for RRC_CONNECTED UEs Intel Corporation
R1-2200428 Discussion on MBS reliability improvement for RRC_CONNECTED UEs Apple
R1-2200472 On reliability improvement for RRC-CONNECTED UEs Lenovo, Motorola Mobility
R1-2200513 Remaining Issues on Reliability Improvements for RRC_CONNECTED UEs NEC
R1-2200526 PUCCH formats for enhancement to NACK-ONLY based HARQ-ACK feedback TD Tech, Chengdu TD Tech
R1-2200550 Remaining issues on improve multicast reliability for RRC_CONNECTED UEs MediaTek Inc.
R1-2200579 Mechanisms to improve reliability of Broadcast/Multicast service LG Electronics
R1-2200597 Remaining issues on reliability improvement for RRC_CONNECTED UEs CMCC
R1-2200666 Discussion on reliability mechanisms for NR MBS Ericsson
[107bis-e-R17-MBS-02] – Jinhuan (Huawei)
Email discussion/approval on mechanisms to improve reliability for RRC_CONNECTED UEs
- 1st check point: January 20
- Final check point: January 25
R1-2200717 FL summary#1 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
From Jan 18th GTW session
Agreement
When PUCCH carrying multicast HARQ-ACK only overlaps with PUSCH with the same priority, support UL-DAI indicating the number of HARQ-ACK bits for multicast as defined in Rel-16 for unicast HARQ-ACK.
· FFS it is applied to a single G-RNTI or applied to all configured G-RNTIs.
Agreement
Support multiplexing unicast and multicast HARQ-ACK onto the same PUSCH with the same priority for the following cases:
Decision: As per email decision posted on Jan 21st,
Agreement
The TP below for TS38.213v17.0.0 section 18 is endorsed
|
<Unchanged text is omitted> If a UE is provided pucch-Config-Multicast1 or pucch-Config-Multicast2 for PUCCH transmissions with a priority value, the UE transmits a PUCCH with the priority value according to pucch-Config-Multicast1 or pucch-Config-Multicast2 for each G-RNTI or G-CS-RNTI that the UE provides associated HARQ-ACK information according to the first HARQ-ACK reporting mode or second HARQ-ACK reporting mode. <Unchanged text is omitted> |
Agreement
The TP below for TS38.213v17.0.0 section 18 is endorsed
|
<Unchanged text is omitted> A UE monitors PDCCH for scheduling PDSCH receptions or for activation/release of SPS PDSCH receptions for a corresponding SPS PDSCH configuration as described in clause 10.1. A UE can be configured by harq-Feedback-Option-Multicast for a G-RNTI or by sps-HARQ-Feedback-Option-Multicast for a G-CS-RNTI to provide HARQ-ACK information for a transport block reception associated with the G-RNTI or with the G-CS-RNTI, respectively, according to the first HARQ-ACK reporting mode or according to the second HARQ-ACK reporting mode. The second HARQ-ACK reporting mode is not applicable for DCI formats having associated HARQ-ACK information without scheduling a PDSCH reception. For the first HARQ-ACK reporting mode, the UE generates HARQ-ACK information with ACK value when a UE correctly decodes a transport block or detects a DCI format indicating an SPS PDSCH release; otherwise, the UE generates HARQ-ACK information with NACK value, as described in clauses 9 and 9.1 through 9.3. For the second HARQ-ACK reporting mode, the UE does not transmit a PUCCH that would include only HARQ-ACK information with ACK values. <Unchanged text is omitted> |
R1-2200718 FL summary#2 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
Decision: As per email decision posted on Jan 24th,
Agreement
The TP below for TS38.213v17.0.0 section 18 is endorsed.
|
18 Multicast Broadcast Services < Unchanged parts are omitted > A UE determines a PUCCH resource for a PUCCH transmission with HARQ-ACK information as described in clauses 9.2 and 9.2.1 through 9.2.5. If the UE multiplexes HARQ-ACK information associated with unicast DCI formats and HARQ-ACK information associated with multicast DCI formats in a same PUCCH, the last DCI format that the UE uses to determine the PUCCH resource, as described in clause 9.2.3, is a last unicast DCI format. A UE is not required to multiplex in a PUCCH multicast HARQ-ACK and unicast UCI of the same priority if the UE is provided subslotLengthForPUCCH for the PUCCH with the unicast UCI. |
Agreement
When HARQ-ACK for unicast SPS PDSCHs and multicast SPS PDSCHs with ACK/NACK based feedback are multiplexed on the same PUCCH for the same priority case, the PUCCH carrying the multiplexed HARQ-ACK is determined from the SPS-PUCCH-AN-List configured for unicast.
Agreement
When HARQ-ACK for unicast SPS PDSCHs and multicast dynamic grant PDSCHs with ACK/NACK based feedback are multiplexed on the same PUCCH for the same priority case, down-select from:
· Option 1: the PUCCH carrying the multiplexed HARQ-ACK is determined from the SPS-PUCCH-AN-List configured for unicast.
· Option 2: the PUCCH carrying the multiplexed HARQ-ACK is determined from PUCCH-Config/PUCCH-ConfigurationList configured for multicast.
Decision: As per email decision posted on Jan 25th,
Agreement
For the separate PUCCH-Config/ PUCCH-ConfigurationList configured to UE for NACK-only based feedback,
· 1 PUCCH resource set in each PUCCH-Config.
· up to 32 PUCCH resources in PUCCH resource set
· Note: the separate PUCCH-Config/PUCCH-ConfigurationList applies to all configured G-RNTIs configured with NACK-only based feedback.
Agreement
Support pdsch-AggregationFactor configured in PDSCH-Config-Multicast for DCI formats 4_0/4_1, similar as that of DCI format 4_2. The TP below for TS38.214v17.0.0 section 5.1.2.1 is endorsed:
|
5.1.2.1 Resource allocation in time domain *** Unchanged text is omitted *** When receiving PDSCH scheduled by DCI format 4_0/4_1/4_2 in PDCCH with CRC scrambled by G-RNTI or G-CS-RNTI with NDI=1, if the UE is configured with pdsch-AggregationFactor in the pdsch-Config-Multicast associated with the corresponding G-RNTI or in the associated SPS-Config-Multicast activated by the DCI format 4_0/4_1/4_2 with CRC scrambled by G-CS-RNTI, the same symbol allocation is applied across the pdsch-AggregationFactor consecutive slots. When receiving PDSCH scheduled by DCI format 4_0/4_1/4_2 for multicast reception in PDCCH with CRC scrambled by G-CS-RNTI with NDI = 0, or PDSCH without corresponding PDCCH transmission using associated [SPS-Config-Multicast] and activated by the DCI format 4_0/4_1/4_2 in PDCCH with CRC scrambled by G-CS-RNTI, the same symbol allocation is applied across the pdsch-AggregationFactor, in associated SPS-Config-Multicast if configured, or 1 otherwise, consecutive slots. When receiving PDSCH scheduled by DCI format 4_0 in PDCCH with CRC scrambled by G-RNTI for MTCH, if the UE is configured with pdsch-AggregationFactor in the pdsch-Config-Broadcast, the same symbol allocation is applied across the pdsch-AggregationFactor consecutive slots. When receiving PDSCH scheduled by DCI in PDCCH with CRC scrambled by G-CS-RNTI for multicast reception or G-RNTI, if the DCI field 'Time domain resource assignment' indicates an entry which contains repetitionNumber in PDSCH-TimeDomainResourceAllocation in the PDSCH-Config-Multicast or PDSCH-Config-Broadcast, the same SLIV is applied for all PDSCH transmission occasions across the repetitionNumber consecutive slots. When receiving PDSCH scheduled without corresponding PDCCH transmission using associated SPS-Config-Multicast and activated by DCI in PDCCH with CRC scrambled by G-CS-RNTI for multicast reception, if the DCI field 'Time domain resource assignment' of the activating DCI indicates an entry which contains repetitionNumber in PDSCH-TimeDomainResourceAllocation in the PDSCH-Config-Multicast, the same SLIV is applied for all PDSCH transmission occasions across the repetitionNumber consecutive slots. |
Agreement
For multicast SPS PDSCH re-transmission, the pdsch-AggregationFactor in pdsch-Config-Multicast is applied as the repetition number. The TP below for TS38.214v17.0.0 section 5.1.2.1 is endorsed:
|
5.1.2.1 Resource allocation in time domain <Unchanged text is omitted> When
receiving PDSCH scheduled by DCI format 4_2 in PDCCH with CRC scrambled by
G-RNTI or G-CS-RNTI with NDI=1, if the UE is configured with pdsch-AggregationFactor
in the pdsch-Config-Multicast associated with the corresponding
G-RNTI or <Unchanged text is omitted> |
Agreement
When UE is configured with unicast SPS and multicast SPS with ACK/NACK based feedback for multiplexing on the same PUCCH for the same priority case, the HARQ-ACK codebook is constructed as for multiple SPS PDSCHs regardless of unicast SPS PDSCH or multicast SPS PDSCH.
Agreement
When HARQ-ACK for multicast dynamic grant PDSCHs and multicast SPS PDSCHs with ACK/NACK based feedback are multiplexed on the same PUCCH for the same priority case, the PUCCH carrying the multiplexed HARQ-ACK is determined from PUCCH-Config/PUCCH-ConfigurationList configured for multicast.
Agreement
Extending the fallback operation for Type-1 HARQ-ACK codebook to multicast PDSCH receptions.
· FFS how to handle the fallback operation for the case of multiple G-RNTIs/G-CS-RNTIs configured
· FFS how to handle the fallback operation for the case that PTP retransmission is used for PTM initial transmission.
Final summary in R1-2200719.
R1-2200029 Discussion on UE receiving broadcast in RRC IDLE/INACTIVE state Huawei, HiSilicon, CBN
R1-2200096 Remaining issues on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs vivo
R1-2200119 Discussion on basic Functions for Broadcast or Multicast for RRC_IDLE or RRC_INACTIVE UEs ZTE
R1-2200159 Remaining Issues on Broadcast / Multicast for RRC_IDLE / RRC_INACTIVE UEs Nokia, Nokia Shanghai Bell
R1-2200215 Remaining issues on broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs Samsung
R1-2200245 Remaining issues on basic functions for broadcast NTT DOCOMO, INC.
R1-2200310 Maintenance on group scheduling for Broadcast RRC_IDLE-INACTIVE UEs Qualcomm Incorporated
R1-2200352 Discussion on remaining issues of basic functions for RRC_IDLE/RRC_INACTIVE UEs OPPO
R1-2200388 Broadcast for RRC_IDLE/INACTIVE UEs Intel Corporation
R1-2200429 Discussion on MBS for RRC_IDLE and RRC_INACTIVE UEs Apple
R1-2200452 Discussion on basic functions for broadcast/multicast for RRC_IDLERRC_INACTIVE UEs xiaomi
R1-2200473 Basic functions for broadcast/multicast in idle/inactive states Lenovo, Motorola Mobility
R1-2200527 Discussion on basic functions for broadcast mode TD Tech, Chengdu TD Tech
R1-2200551 Remaining issues on MBS broadcast reception for RRC_IDLE and INACTIVE UEs MediaTek Inc.
R1-2200580 Basic function for broadcast/multicast LG Electronics
R1-2200598 Remaining issues on NR MBS in RRC_IDLE RRC_INACTIVE states CMCC
R1-2200646 Views on overall configuration for broadcast scheduling Huawei, HiSilicon
R1-2200667 Support for NR broadcast reception in RRC Inactive/Idle Ericsson
[107bis-e-R17-MBS-03] – Le Liu (Qualcomm)
Email discussion/approval on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs
- 1st check point: January 20
- Final check point: January 25
R1-2200705 FL summary #1 on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs Moderator (Qualcomm)
From Jan 20th GTW session
Agreement
For RRC_IDLE/INACTIVE UEs, a UE is not required to support reception of FDMed MCCH PDSCH and MTCH PDSCH in PCell.
Agreement
For RRC_IDLE/INACTIVE UEs, a UE is not required to support reception of FDMed multiple MTCH PDSCHs in PCell.
Agreement
For RRC_IDLE/INACTIVE UEs, a UE is not required to support reception of FDMed MCCH/MTCH PDSCH and SIB1 or Paging PDSCH in PCell.
· FFS: PBCH and other SIBs
Conclusion
Additional HARQ process(es) is(are) not introduced for Rel-17 MBS broadcast reception on serving cell.
· Note: The UE is not expected to support hardware for more HARQ processes for receiving broadcast in Rel-17 in addition to the maximum number of HARQ processes supported for receiving unicast in Rel-16, i.e. the HARQ process resources are shared between broadcast, unicast and multicast
Decision: As per email decision posted on Jan 21st,
Agreement
The TP below for Section 5.1.2.1 of TS 38.214v17.0.0 is endorsed.
|
5.1.2.1 Resource allocation in time domain < Unchanged parts are omitted > When receiving PDSCH scheduled by DCI format 4_2 in PDCCH with CRC scrambled by G-RNTI or G-CS-RNTI with NDI=1, if the UE is configured with pdsch-AggregationFactor in the pdsch-Config-Multicast associated with the corresponding G-RNTI or in the associated SPS-Config-Multicast activated by the DCI format 4_2 with CRC scrambled by G-CS-RNTI, the same symbol allocation is applied across the pdsch-AggregationFactor consecutive slots. When receiving PDSCH scheduled by DCI format 4_2 for multicast reception in PDCCH with CRC scrambled by G-CS-RNTI with NDI = 0, or PDSCH without corresponding PDCCH transmission using associated [SPS-Config-Multicast] and activated by the DCI format 4_2 in PDCCH with CRC scrambled by G-CS-RNTI, the same symbol allocation is applied across the pdsch-AggregationFactor, in associated SPS-Config-Multicast if configured, or 1 otherwise, consecutive slots. When receiving PDSCH scheduled by DCI format 4_0 in PDCCH with CRC scrambled by G-RNTI for MTCH, if the UE is configured with pdsch-AggregationFactor in the pdsch-Config-MTCH, the same symbol allocation is applied across the pdsch-AggregationFactor consecutive slots. |
Agreement
The TP below for Section 5.1.2.3 of TS 38.214v17.0.0 is endorsed.
|
----- Start of Text proposal to 5.1.2.3 of 38.214 ----- < Unchanged parts are omitted > If a UE is scheduled a PDSCH with DCI format 1_0 or DCI
format 4_0, the UE shall assume that < Unchanged parts are omitted > ----- End of Text proposal to 5.1.2.3 of 38.214 ------ |
Agreement
The TP below for Section 5.1.3.1 of TS 38.214v17.0.0 is endorsed.
|
5.1.3.1 Modulation order and target code rate determination < Unchanged parts are omitted > elseif the higher layer parameter mcs-Table given by PDSCH-Config is set to ‘qam256’, and the PDSCH is scheduled by a PDCCH with DCI format 1_1 with CRC scrambled by C-RNTI - the UE shall use IMCS and Table 5.1.3.1-2 to determine the modulation order (Qm) and Target code rate ® used in the physical downlink shared channel. Elseif the higher layer parameter mcs-Table given by PDSCH-Config-Multicast is set to ‘qam256’, and the PDSCH is scheduled by a PDCCH with DCI format 4_1 or 4_2 with CRC scrambled by G-RNTI - the UE shall use IMCS and Table 5.1.3.1-2 to determine the modulation order (Qm) and Target code rate ® used in the physical downlink shared channel. Elseif the higher layer parameter mcs-Table given by PDSCH-Config-MCCH and PDSCH-Config-MTCH is set to ‘qam256’, and the PDSCH is scheduled by a PDCCH with DCI format 4_0 with CRC scrambled by MCCH-RNTI or G-RNTI for MTCH - the UE shall use IMCS and Table 5.1.3.1-2 to determine the modulation order (Qm) and Target code rate ® used in the physical downlink shared channel. |
Agreement
The TP below for Section 5.1.6.2 of TS 38.214v17.0.0 is endorsed.
|
----------------------------------- Start of Text proposal to 5.1.6.2 of 38.214 ------------------------------------------------ < Unchanged parts are omitted > When receiving PDSCH scheduled by DCI format 1_0 or DCI format 4_0 or receiving PDSCH before dedicated higher layer configuration of any of the parameters dmrs-AdditionalPosition, maxLength and dmrs-Type, the UE shall assume that the PDSCH is not present in any symbol carrying DM-RS except for PDSCH with allocation duration of 2 symbols with PDSCH mapping type B (described in clause 7.4.1.1.2 of [4, TS 38.211]), and a single symbol front-loaded DM-RS of configuration type 1 on DM-RS port 1000 is transmitted, and that all the remaining orthogonal antenna ports are not associated with transmission of PDSCH to another UE and in addition <Unchanged text omitted> When receiving PDSCH scheduled by DCI format 1_0 or DCI format 4_0, the UE shall assume the number of DM-RS CDM groups without data is 1 which corresponds to CDM group 0 for the case of PDSCH with allocation duration of 2 symbols, and the UE shall assume that the number of DM-RS CDM groups without data is 2 which corresponds to CDM group {0,1} for all other cases. < Unchanged parts are omitted > ----------------------------------- End of Text proposal to 5.1.6.2 of 38.214 ------------------------------------------------ |
Agreement
The TP below for Section 5.4.2.1 of TS 38.212v17.0.0 is endorsed.
|
5.4.2.1 Bit selection < Unchanged parts are omitted > Table
5.4.2.1-1: Value of
< Unchanged parts are omitted > |
Agreement
The TP below for Section 7.3.1.5.1 of TS 38.212v17.0.0 is endorsed.
|
7.3.1.5.1 Format 4_0 The following information is transmitted by means of the DCI format 4_0 with CRC scrambled by MCCH-RNTI or G-RNTI for MTCH configured by MBS-SessionInfo: - Frequency domain
resource assignment – - the size of CORESET 0 if CORESET 0 is configured for the cell; and - the size of initial DL bandwidth part if CORESET 0 is not configured for the cell. < Unchanged parts are omitted > |
R1-2200706 FL summary #2 on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs Moderator (Qualcomm)
From Jan 24th GTW session
Agreement
The dataScramblingIdentityPDSCH-Broadcast, and scramblingID0-Broadcast can be separately configured for MCCH-RNTI and for each MTCH G-RNTI.
Agreement
For broadcast RRC_IDLE/INACTIVE UEs, rateMatchPatternToAddModList can be configured in PDSCH-Config-MCCH or PDSCH-Config-MTCH for GC-PDSCH rate matching.
· Whether UE can receive the GC-PDSCH with rate matching based on the rateMatchPatternToAddModList is subject to UE capability.
· Rel-15/16 UE capability of the supported maximum number of RE mapping patterns per symbol and per slot are kept unchanged to support rate matching for unicast/multicast/broadcast. The RateMatchPattern configured for MBS broadcast is counted into the ones that are configured per serving-cell.
Agreement
For RRC_IDLE/INACTIVE UEs, a UE is not required to support reception of FDMed MCCH/MTCH PDSCH and SIB PDSCH in PCell.
R1-2200707 FL summary #3 on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs Moderator (Qualcomm)
Decision: As per email decision posted on Jan 25th,
Agreement
New data indicator is not indicated in DCI format 4_0 for MCCH.
Agreement
HARQ process ID is not indicated in DCI format 4_0 for both MCCH and MTCH.
Agreement
New data indicator is not indicated in DCI format 4_0 for MTCH.
Agreement
The TP below for Section 10 of TS 38.213v17.0.0 is endorsed.
|
10.1 UE procedure for determining physical downlink control channel assignment A set of PDCCH candidates for a UE to monitor is defined in terms of PDCCH search space sets. A search space set can be a CSS set or a USS set. A UE monitors PDCCH candidates in one or more of the following search spaces sets - a Type0-PDCCH CSS set configured by pdcch-ConfigSIB1
in MIB or by searchSpaceSIB1 in PDCCH-ConfigCommon or by
searchSpaceZero in PDCCH-ConfigCommon for a DCI format 1_0 with
CRC scrambled by a SI-RNTI, or by searchSpaceZero in PDCCH-ConfigCommon
when
neither pdcch-Config-MCCH nor
pdcch-Config- ---------------------------- Other parts are omitted. ---------------------------- |
Agreement
· If the active DL BWP and the common MBS frequency resource for broadcast have same SCS and same CP length and the active DL BWP includes all RBs of the common MBS frequency resource configured for broadcast and if a UE is provided searchSpace for Type0B-PDCCH CSS set, the UE monitors PDCCH for Type0B-PDCCH CSS set on the DL BWP.
o Note: It is up to the editor how to capture the above.
· The TP below for section 10.1 of TS 38.213v17.0.0 is endorsed
|
10.1 UE procedure for determining physical downlink control channel assignment < Unchanged parts are omitted > For a DL BWP, if a UE is not provided searchSpaceSIB1 for Type0-PDCCH CSS set by PDCCH-ConfigCommon, the UE does not monitor PDCCH candidates for a Type0-PDCCH CSS set on the DL BWP. The Type0-PDCCH CSS set is defined by the CCE aggregation levels and the number of PDCCH candidates per CCE aggregation level given in Table 10.1-1. If the active DL BWP and the initial DL BWP have same SCS and same CP length and the active DL BWP includes all RBs of the CORESET with index 0, or the active DL BWP is the initial DL BWP, or the active DL BWP includes all RBs of the common MBS frequency resource configured for broadcast, the CORESET configured for Type0-PDCCH CSS set has CORESET index 0 and the Type0-PDCCH CSS set has search space set index 0. < Unchanged parts are omitted > |
Agreement
The TP below for Section 7.3.1.5 of TS 38.211v17.0.0 is endorsed.
|
7.3.1.5 Mapping to virtual resource blocks
The
UE shall, for each of the antenna ports used for transmission of the physical
channel, assume the block of complex-valued symbols - they are in the virtual resource blocks assigned for transmission; - the corresponding physical resource blocks are declared as available for PDSCH according to clause 5.1.4 of [6, TS 38.214]; - the corresponding resource elements in the corresponding physical resource blocks are - not used for transmission of the associated DM-RS or DM-RS intended for other co-scheduled UEs as described in clause 7.4.1.1.2; - not used for non-zero-power CSI-RS
according to clause 7.4.1.5 if the corresponding physical resource blocks are
for a PDSCH scheduled by a PDCCH with the CRC scrambled by C-RNTI,
MCS-C-RNTI, CS-RNTI, G-RNTI for multicast,
G-CS-RNTI, - not used for PT-RS according to clause 7.4.1.2; - not declared as 'not available for PDSCH according to clause 5.1.4 of [6, TS 38.214].
---------------------------- Other parts are omitted. ---------------------------- |
R1-2200097 Other issues for Rel-17 MBS vivo
R1-2200120 Discussion on RRC parameters of Rel-17 MBS ZTE
R1-2200683 Discussion on other issues in Rel-17 MBS CATT, CBN (rev of R1-2200135)
R1-2200453 Other remaining issues for MBS xiaomi
R1-2200528 Discussion on typical configuration for NR MBS TD Tech, Chengdu TD Tech
R1-2200581 Other aspects for MBS LG Electronics
R1-2200617 Discussion on further improvements for MBS ASUSTeK
R1-2200668 Assumptions for performance evaluations of NR-MBS Ericsson
R1-2202790 Session notes for 8.12 (Maintenance on NR Multicast and Broadcast Services) Ad-Hoc Chair (Huawei)
[108-e-R17-RRC-MBS] – Fei (CMCC)
Email discussion on Rel-17 RRC parameters for NR MBS
- 1st check point for first LS in [108-e-R17-RRC]: February 24
- Final check point for second LS in [108-e-R17-RRC] if necessary: March 3
R1-2202664 Summary of email discussion on Rel-17 RRC parameters for NR MBS Moderator (CMCC, Huawei, BBC)
Document is noted. For consolidation under 8 in [108-e-R17-RRC].
R1-2202946 Agreements for NR MBS up to RAN1#108 WI rapporteur (CMCC)
R1-2200948 Resource configuration and group scheduling for RRC_CONNECTED UEs Huawei, HiSilicon
R1-2201006 Remaining Issues on Group Scheduling Mechanisms for RRC_CONNECTED UEs supporting MBS Nokia, Nokia Shanghai Bell
R1-2201114 Remaining issues on mechanisms to support group scheduling for RRC_CONNECTED UEs vivo
R1-2201170 Maintenance of Mechanisms to Support Group Scheduling for RRC_CONNECTED UEs ZTE
R1-2201257 Discussion on remaining issues of group scheduling mechanism for RRC_CONNECTED UEs OPPO
R1-2201338 Remaining issue on group scheduling mechanism for RRC_CONNECTED UEs in MBS CATT
R1-2201496 Remaining issues on group scheduling mechanisms for RRC_CONNECTED UEs NTT DOCOMO, INC.
R1-2201592 Discussion on RAN2 LS on MBS SPS TD Tech, Chengdu TD Tech
R1-2201607 Discussion on mechanisms to support group scheduling for RRC_CONNECTED UEs ASUSTeK
R1-2201717 Group Scheduling for RRC_CONNECTED UEs Intel Corporation
R1-2201786 Remaining issues on MBS group scheduling mechanism for RRC_connected UEs Apple
R1-2201815 Discussion on the remaining issues on MBS group scheduling for RRC_CONNETED UEs Spreadtrum Communications
R1-2201876 Remaining issues on group scheduling mechanisms for RRC_CONNECTED UEs CMCC
R1-2201908 Remaining Issues on Group Scheduling Mechanisms for RRC_CONNECTED UEs NEC
R1-2201931 Remaining issues on group scheduling for RRC_CONNECTED UEs Xiaomi
R1-2202034 Maintenance on group scheduling for RRC_CONNECTED UEs Samsung
R1-2202079 Remaining issues on NR MBS group scheduling for RRC_CONNECTED UEs MediaTek Inc.
R1-2202160 Maintenance on group scheduling for Multicast RRC_CONNECTED UEs Qualcomm Incorporated
R1-2202227 Remaining issues on group scheduling mechanism for RRC_CONNECTED UEs Lenovo, Motorola Mobility
R1-2202232 Correction on group scheduling for RRC_CONNECTED UEs ETRI
R1-2202331 Corrections of MBS for RRC_CONNECTED UEs Google Inc.
R1-2202349 Support of group scheduling for RRC_CONNECTED UEs LG Electronics
R1-2202396 Mechanisms to support MBS group scheduling for RRC_CONNECTED UEs Ericsson
[108-e-R17-MBS-01] – Fei (CMCC)
Email discussion for maintenance on mechanisms to support group scheduling for RRC_CONNECTED UEs
- 1st check point: February 25
- Final check point: March 3
R1-2202580 Summary#2 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC) (rev of R1-2201875)
From Feb 21st GTW session
Agreement
In the reply LS on MBS SPS to RAN2, capture the following for Q1:
· RAN1 confirms that RAN2’s understanding is correct.
· RAN1 thinks that the maximum number of G-CS-RNTI configured for UE should be subject to UE capability.
Agreement
In the reply LS on MBS SPS to RAN2, capture the following for Q2:
R1-2202641 Summary#5 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC) (rev of R1-2202582, rev of R1-2202581)
Decision: As per email decision posted on Feb 25th
Agreement
RAN1 thinks that multiple G-CS-RNTIs cannot be mapped to same MBS SPS-config at the same time for a UE.
Drafting the reply LS on MBS SPS (see below R1-2202591) that includes the above 3 agreements.
Agreement
Send an LS to inform RAN2 that the following parameters are NOT needed for PDCCH-Config-Multicast:
· downlinkPreemption
· tpc-PUCCH
· tpc-PUSCH
· tpc-SRS
· uplinkCancellation-r16
· monitoringCapabilityConfig-r16 (the default is R15monitoringcapablity)
· searchSpaceSwitchConfig-r16
Agreement
Send an LS to inform RAN2 that the following parameters are NOT needed for PDSCH-Config-Multicast:
· minimumSchedulingOffsetK0-r16
· antennaPortsFieldPresenceDCI-1-2-r16, aperiodicZP-CSI-RS-ResourceSetsToAddModListDCI-1-2-r16, aperiodicZP-CSI-RS-ResourceSetsToReleaseListDCI-1-2-r16, dmrs-DownlinkForPDSCH-MappingTypeA-DCI-1-2-r16, dmrs-DownlinkForPDSCH-MappingTypeB-DCI-1-2-r16, dmrs-SequenceInitializationDCI-1-2-r16, harq-ProcessNumberSizeDCI-1-2-r16, mcs-TableDCI-1-2-r16, numberOfBitsForRV-DCI-1-2-r16, pdsch-TimeDomainAllocationListDCI-1-2-r16, prb-BundlingTypeDCI-1-2-r16, priorityIndicatorDCI-1-2-r16, rateMatchPatternGroup1DCI-1-2-r16, rateMatchPatternGroup2DCI-1-2-r16, resourceAllocationType1GranularityDCI-1-2-r16, vrb-ToPRB-InterleaverDCI-1-2-r16, referenceOfSLIVDCI-1-2-r16, resourceAllocationDCI-1-2-r16,
· dataScramblingIdentityPDSCH2-r16
· repetitionSchemeConfig-r16, repetitionSchemeConfig-v1630
Agreement
If UE supports carrier aggregation for unicast, multicast reception on an activated SCell with self-scheduling is supported subject to UE capability in Rel-17.
· UE is not expected to be configured simultaneously with more than one component carrier for multicast reception.
· Cross-carrier scheduling for multicast reception is not supported in Rel-17.
· The capability of supporting MBS multicast on SCell is a separate capability from the CA capability for unicast.
o The granularity of UE reporting the capability of supporting MBS multicast reception is per FSPC
Conclusion
When HARQ feedback is disabled, the following fields (if present) of DCI format 4_1/4_2 can be assumed to be reserved and UE ignores them:
· PUCCH resource Indicator
· PDSCH-to-HARQ_feedback timing indicator
Agreement
For RRC_CONNECTED UEs, a multicast PDCCH to schedule a multicast PDSCH is counted as a unicast DCI to schedule a unicast PDSCH.
· Adopt the following TP for Clause 10.1 in TS 38.213:
----------------- Start of TP ----------------
10.1 UE procedure for determining physical downlink control channel assignment
<Unchanged text is omitted>
For a scheduled cell and at any time, a UE expects to have received at most 16 PDCCHs for DCI formats with CRC scrambled by C-RNTI, CS-RNTI, G-RNTI for multicast, G-CS-RNTI or MCS-C-RNTI scheduling 16 PDSCH receptions for which the UE has not received any corresponding PDSCH symbol and at most 16 PDCCHs for DCI formats with CRC scrambled by C-RNTI, CS-RNTI, or MCS-C-RNTI scheduling 16 PUSCH transmissions for which the UE has not transmitted any corresponding PUSCH symbol.
<Unchanged text is omitted>
----------------- End of TP ----------------
Agreement
· “Initial TP 2-6-2” in section 7 of R1-2202641 is endorsed for Clause 7.3.1.5.2 in TS 38.212.
· “Initial TP 2-6-2” in section 7 of R1-2202641 is endorsed for Clause 7.3.1.5.3 in TS 38.212.
· “Initial TP 2-6-3” in section 7 of R1-2202641 is endorsed for Clause 10.2 in TS 38.213.
Agreement
Regarding rate matching of GC-PDSCH reception, the UE shall assume that both of indicated resources in clauses 5.1.4.1, 5.1.4.2 and the PRBs containing SS/PBCH block transmission resources are not available for the PDSCH scheduled with G-RNTI for multicast.
· Adopt the following TP for Clause 5.1.4 of TS38.214
----------------- Start of TP ----------------
5.1.4 PDSCH resource mapping
<Unchanged text is omitted>
When receiving the PDSCH scheduled with SI-RNTI and the system information indicator in DCI is set to 0, the UE shall assume that no SS/PBCH block is transmitted in REs used by the UE for a reception of the PDSCH.
When receiving the PDSCH scheduled with SI-RNTI and the system information indicator in DCI is set to 1, RA-RNTI, MSGB-RNTI, P-RNTI or TC-RNTI, the UE assumes SS/PBCH block transmission according to ssb-PositionsInBurst, and if the PDSCH resource allocation overlaps with PRBs containing SS/PBCH block transmission resources the UE shall assume that the PRBs containing SS/PBCH block transmission resources are not available for PDSCH in the OFDM symbols where SS/PBCH block is transmitted.
A UE expects a configuration provided by ssb-PositionsInBurst in ServingCellConfigCommon to be same as a configuration provided by ssb-PositionsInBurst in SIB1.
When receiving PDSCH scheduled by PDCCH with CRC scrambled by C-RNTI, MCS-C-RNTI, CS-RNTI, G-RNTI for multicast or PDSCHs with SPS, the REs corresponding to the configured or dynamically indicated resources in Clauses 5.1.4.1, 5.1.4.2 are not available for PDSCH. Furthermore, the UE assumes SS/PBCH block transmission according to ssb-PositionsInBurst if the PDSCH resource allocation overlaps with PRBs containing SS/PBCH block transmission resources, and the UE shall assume that the PRBs containing SS/PBCH block transmission resources are not available for PDSCH in the OFDM symbols where SS/PBCH block is transmitted.
<Unchanged text is omitted>
----------------- End of TP ----------------
Decision: As per email decision posted on Feb 26th,
Agreement
Regarding the number of DCIs that a UE can process in a slot or span, MBS broadcast DCI monitored by the UE is treated as unicast DCI scheduling DL following the current feature group 3-1/3-5a/3-5b for RRC_CONNECTED UEs.
Agreement
Adopt the following TP for Clause 7.3.1.5.3 in TS 38.212:
----------------- Start of TP ----------------
7.3.1.5.3 Format 4_2
<Unchanged text is omitted>
- Rate matching indicator – 0, 1, or 2 bits according to higher layer parameters rateMatchPatternGroup1 and rateMatchPatternGroup2 in PDSCH-Config-Multicast, where the MSB is used to indicate rateMatchPatternGroup1 and the LSB is used to indicate rateMatchPatternGroup2 when there are two groups.
- ZP
CSI-RS trigger – 0, 1, or 2 bits as defined in Clause 5.1.4.2 of [6, TS
38.214]. The bitwidth for this field is determined as 
bits, where 
is the number of aperiodic ZP CSI-RS
resource sets configured in PDSCH-Config-Multicast
by higher layer.
<Unchanged text is omitted>
----------------- End of TP ----------------
R1-2200888 LS on MBS SPS RAN2, OPPO
R1-2202591 Reply LS on MBS SPS RAN1, CMCC
Decision: As per email decision posted on Feb 27th, the LS is approved.
R1-2202642 Summary#6 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
From Feb 28th GTW session
Agreement
Send an LS to inform RAN2 that the following parameters are NOT needed for PDSCH-Config-Multicast:
· zp-CSI-RS-ResourceToAddModList, zp-CSI-RS-ResourceToReleaseList
Agreement
For multicast RRC_CONNECTED UEs, p-ZP-CSI-RS-ResourceSet can be configured in PDSCH-Config-Multicast for GC-PDSCH rate matching, subject to UE capability. For PDSCH resource mapping with RE symbol level granularity,
· the REs indicated by p-ZP-CSI-RS-ResourceSet configured in PDSCH-Config-Multicast are declared as not available for GC-PDSCH.
· p-ZP-CSI-RS-ResourceSet configured in PDSCH-Config for unicast do not apply for GC-PDSCHs.
· p-ZP-CSI-RS-ResourceSet in PDSCH-Config-Multicast for multicast do not apply for unicast PDSCHs.
· The total number of p-ZP-CSI-RS-ResourceSet that a UE can be configured with is the same as for unicast in Rel-16
Also include this agreement in an LS to RAN2.
Agreement
For multicast RRC_CONNECTED UEs, sp-ZP-CSI-RS-ResourceSetsToAddModList can be configured in PDSCH-Config-Multicast for GC-PDSCH rate matching, subject to UE capability. For PDSCH resource mapping with RE symbol level granularity,
· the REs indicated by sp-ZP-CSI-RS-ResourceSetsToAddModList configured in PDSCH-Config-Multicast are declared as not available for GC-PDSCH when their activation delivered by unicast PDSCH is applied.
· sp-ZP-CSI-RS-ResourceSetsToAddModList configured in PDSCH-Config for unicast do not apply for GC-PDSCHs.
· sp-ZP-CSI-RS-ResourceSetsToAddModList in PDSCH-Config-Multicast for multicast do not apply for unicast PDSCHs.
· The total number of semi-persistent ZP-CSI-RS-ResourceSet that a UE can be configured with is the same as for unicast in Rel-16
Also include this agreement in an LS to RAN2.
Agreement
For TCI states activation/deactivation for multicast GC-PDSCH, Alt-1 is supported.
· Alt-1: The unicast PDSCH carrying a ‘TCI States Activation/Deactivation for UE-specific PDSCH MAC CE’ is received by the UE to map up to 8 TCI states configured in PDSCH-Config to the TCI codepoints in both unicast DCI format and DCI format 4_2. The following text in Clause 5.1.5 of TS38.214 is deleted.
o “The UE can be configured with a list of up to M’ TCI-State configurations within the higher layer parameter PDSCH-Config-Multicast to decode PDSCH associated with a G-RNTI or a G-CS-RNTI according to a detected PDCCH with DCI intended for the UE and the given serving cell, where M’ depends on the UE capability.”
R1-2202746 FL summary#1 on MBS broadcast reception on SCell Moderator (Huawei)
From Mar 1st GTW session
Agreement
Adopt the following TP for Clause 10.1 in TS 38.213:
· note: further clarification may be needed for the case of receiving broadcast, and MCCH-RNTI
----------------- Start of TP ----------------
10.1 UE procedure for determining physical downlink control channel assignment
<Unchanged text is omitted>
For
a scheduled cell and at any time, if a UE is
provided a C-RNTI, athe UE expects to have received at most 16 PDCCHs
for DCI formats with CRC scrambled by C-RNTI, CS-RNTI, G-RNTI, G-CS-RNTI or MCS-C-RNTI
scheduling 16 PDSCH receptions for which the UE has not received any
corresponding PDSCH symbol and at most 16 PDCCHs for DCI formats with CRC
scrambled by C-RNTI, CS-RNTI, or MCS-C-RNTI scheduling 16
PUSCH transmissions for which the UE has not transmitted any corresponding
PUSCH symbol.
<Unchanged text is omitted>
----------------- End of TP ----------------
Agreement
Send the LS reply with the following answer to Q1 from the incoming LS (R1-2202727):
· From RAN1 perspective, UE receiving SIBx directly from SCell via BCCH is not feasible since it is legacy procedure that UE is not required to monitor DCI formats associated with SI-RNTI, P-RNTI, RA-RNTI in SCell. Such procedure is expected to be unchanged because of the impact to RAN1 specifications and UE implementation.
Agreement
Send the LS reply with the following answer to Q2 from the incoming LS (R1-2202727):
· From RAN1 perspective, UE can receive MCCH directly from SCell and there is no need to provide MCCH to UE with dedicated signalling. There is no dependency between SIBx reception method for SCell (i.e. directly reading from SCell vs. dedicated RRC signalling) and MCCH provision method (i.e. dedicated signalling vs. directly reading from SCell).
R1-2202821 DRAFT LS reply on MBS broadcast reception on SCell Moderator (Huawei)
Decision: As per email decision posted on Mar 1st, the draft LS is endorsed. Final LS is approved in R1-2202822.
Final summary on MBS broadcast reception on SCell in R1-2202747.
R1-2202827 Summary#7 on mechanisms to support group scheduling for RRC_CONNECTED UEs for NR MBS Moderator (CMCC)
From Mar 3rd GTW session
Agreement
Update the previous agreement for p-ZP-CSI-RS-ResourceSet as below:
For multicast RRC_CONNECTED UEs, p-ZP-CSI-RS-ResourceSet can be configured in PDSCH-Config-Multicast for GC-PDSCH rate matching, subject to UE capability. For PDSCH resource mapping with RE symbol level granularity,
· the REs indicated by p-ZP-CSI-RS-ResourceSet configured in PDSCH-Config-Multicast are declared as not available for GC-PDSCH.
· p-ZP-CSI-RS-ResourceSet configured in PDSCH-Config for unicast do not apply for GC-PDSCHs.
· p-ZP-CSI-RS-ResourceSet in PDSCH-Config-Multicast for multicast do not apply for unicast PDSCHs.
·
The total number of periodic ZP-CSI-RS-Resources p-ZP-CSI-RS-ResourceSet that a UE can be
configured with is the same as for unicast in Rel-16
o If p-ZP-CSI-RS-ResourceSet is configured in both PDSCH-Config and PDSCH-Config-Multicast, it is subject to UE capability whether the p-ZP-CSI-RS-ResourceSet configured in PDSCH-Config-Multicast can be different from the p-ZP-CSI-RS-ResourceSet configured in PDSCH-Config.
Also include this agreement in an LS to RAN2.
R1-2200949 Mechanisms to improve reliability for RRC_CONNECTED UEs Huawei, HiSilicon
R1-2201007 Remaining Issues on Reliability Improvements for RRC_CONNECTED UEs supporting MBS Nokia, Nokia Shanghai Bell
R1-2201115 Remaining issues on mechanisms to improve reliability for RRC_CONNECTED UEs vivo
R1-2201171 Maintenance of Mechanisms to Improve Reliability for RRC_CONNECTED UEs ZTE
R1-2201258 Remaining issues on UL feedback for RRC-CONNECTED UEs in MBS OPPO
R1-2201339 Remaining issue on reliability improvement mechanism for RRC_CONNECTED UEs in MBS CATT
R1-2201497 Remaining details on HARQ-ACK feedback procedure for multicast NTT DOCOMO, INC.
R1-2201595 Open issues on reliability for NR MBS TD Tech, Chengdu TD Tech
R1-2201718 Reliability for RRC_CONNECTED UEs Intel Corporation
R1-2201787 Remaining issues on MBS reliability improvement for RRC_CONNECTED UEs Apple
R1-2201816 Discussion on the remaining issues on mechanisms to improve MBS reliability for RRC_CONNECTED UEs Spreadtrum Communications
R1-2201877 Remaining issues on reliability improvement for RRC_CONNECTED UEs CMCC
R1-2201909 Remaining Issues on Reliability Improvements for RRC_CONNECTED UEs NEC
R1-2202035 Maintenance on mechanisms to improve reliability Samsung
R1-2202080 Remaining issues on improve multicast reliability for RRC_CONNECTED UEs MediaTek Inc.
R1-2202161 Maintenance on UE feedback for Multicast RRC_CONNECTED UEs Qualcomm Incorporated
R1-2202228 Remaining issues on reliability improvement for RRC-CONNECTED UEs Lenovo, Motorola Mobility
R1-2202233 Remaining issues on mechanisms to improve reliability for RRC_CONNECTED UEs ETRI
R1-2202350 Mechanisms to improve reliability of Broadcast/Multicast service LG Electronics
R1-2202397 Mechanisms to improve reliability for RRC_CONNECTED UEs Ericsson
[108-e-R17-MBS-02] – Jinhuan (Huawei)
Email discussion/approval on mechanisms to improve reliability for RRC_CONNECTED UEs
- 1st check point: February 25
- Final check point: March 3
R1-2202576 FL summary#1 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
R1-2202577 FL summary#2 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
From Feb 24th GTW session
Conclusion
No TP is needed to reflect the RAN1 agreement of the FDMed Type-1 HARQ-ACK codebook for more than one configured G-RNTI,
· Note: it means the following RAN1 agreement is updated as follows, to align with further agreements made in RAN1:
|
Agreement For the Type-1 codebook construction for FDM-ed unicast
and multicast via Opt 4 (from the previous agreement), when UE is configured
with multiple G-RNTIs and UE is configured with fdmed-Reception-Multicast,
the sub-codebook for multicast consists of the HARQ-ACK bits
for all configured G-RNTIs
|
Agreement
For supporting more than one NACK-only feedback in the same PUCCH transmission, define RRC configuration to configure between Alt1 and Alt4 (from previous agreements):
· Alt1: Support UE multiplexing the HARQ-ACK bits by transforming NACK-only into ACK/NACK HARQ bits.
o FFS: how to determine PUCCH resource
· Alt4: Define combination of NACK-only which corresponds to a specific sequence or a PUCCH transmission.
o define up to 15 orthogonal PUCCH resources to select from according to combinations of up to 4 TBs with NACK-only feedback,
§ FFS: The PUCCH slot for the transmission is based on the K1 in the “last DCI” scheduling multicast.
§ FFS: The PUCCH resource for the transmission is from PUCCH-config configured for NACK-only based feedback according to the mapping between number of TBs with PUCCH resource ID.
· FFS mapping details.
· How to determine the number of TBs is discussed separately, e.g., Type-1-like and/or Type-2-like codebook.
§ FFS: whether this applies to a single G-RNTI or multiple G-RNTIs
o Alt4 is not supported for more than 4 TBs
· FFS: whether RRC configuration between Alt1 and Alt4 is per G-RNTI or per CFR
· FFS: UE capability
Decision: As per email decision posted on Feb 25th,
Agreement
When HARQ-ACK for unicast SPS PDSCHs and multicast dynamic grant PDSCHs with ACK/NACK based feedback are multiplexed on the same PUCCH for the same priority case, the following option 1 (from the previous agreement) is adopted:
· Option 1: the PUCCH carrying the multiplexed HARQ-ACK is determined from the SPS-PUCCH-AN-List configured for unicast.
· Option 2: the PUCCH carrying the multiplexed HARQ-ACK is determined from PUCCH-Config/PUCCH-ConfigurationList configured for multicast.
Agreement
When NACK-only based HARQ-ACK feedback is used for multicast SPS PDSCH without PDCCH scheduling, the UE determines a priority index from the HARQ-ACK codebook index in the configuration for SPS multicast, using the same method with the one for ACK/NACK based feedback.
Agreement
When UE is configured with unicast SPS and multicast SPS with NACK-only based feedback for multiplexing on the same PUCCH for the same priority case, NACK only based HARQ-ACK is transformed to ACK/NACK based HARQ-ACK.
· For NACK only based HARQ-ACK transformed to ACK/NACK based HARQ-ACK, the HARQ-ACK codebook is constructed as for multiple SPS PDSCHs regardless of unicast SPS PDSCH or multicast SPS PDSCH and the PUCCH carrying the multiplexed HARQ-ACK is determined from the SPS-PUCCH-AN-List configured for unicast, as agreed for ACK/NACK based feedback.
R1-2202578 FL summary#3 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
From Feb 28th GTW session
Agreement
Regarding RRC configuring Alt1 or Alt4 (from the previous agreement) for multiplexing more than one NACK-only in the same PUCCH transmission, the configuration is per CFR.
Agreement
If Type-1 codebook is configured for both multicast and unicast, at least for single cell case for both unicast and multicast:
· If the UE is configured to construct the HARQ-ACK codebooks for unicast and multicast jointly, a single UL DAI bit applies for unicast and multicast
· Otherwise, 1 additional bit UL DAI is included for multicast in DCI format 0_1/0_2, in addition to the UL DAI for unicast. The 1-bit UL DAI for multicast is applied to all configured G-RNTIs.
o FFS: additional restrictions
Decision: As per email decision posted on Mar 1st,
Agreement
When PUCCH transmission for the NACK-only based feedback for one G-RNTI collides with PUCCH transmission for ACK/NACK feedback for another G-RNTI with the same priority, support UE multiplexing the NACK-only based feedback with the ACK/NACK feedback onto the same PUCCH by transforming NACK-only into the ACK/NACK based HARQ-ACK bit.
· Note: When the TB configured with NACK-only feedback is correctly decoded, the ACK will be transmitted and multiplexed with others.
Agreement
For multiplexing NACK-only feedback for the first G-RNTI with ACK/NACK based feedback for the second G-RNTI or for unicast, down-select from:
· Alt1: the converted NACK-only bits are concatenated to the ACK/NACK feedback.
· Alt2: the codebook construction/concatenation is the same as when the feedback mode is ‘ACK/NACK’ for both G-RNTIs.
Decision: As per email decision posted on Mar 2nd,
Agreement
When UE is configured with enhanced Type-2 codebook for unicast and when the UE is scheduled to multiplex enhanced Type-2 HARQ-ACK for unicast with Type-1 or Type-2 HARQ-ACK codebook for multicast in the same PUCCH slot,
· UE generates separate sub-codebooks for unicast and multicast respectively and appends the multicast HARQ-ACK sub-codebook to the unicast HARQ-ACK sub-codebook.
Agreement
For the following two cases, the fallback operation for the Type-1 HARQ-ACK codebook for multicast is applied to G-RNTI/G-CS-RNTI configured with HARQ-ACK enabled only,
· a SPS PDSCH release indicated by DCI format 4_1 with counter DAI field value of 1,
· a PDSCH reception scheduled by DCI format 4_1 with counter DAI field value of 1 on the PCell,
· SPS PDSCH reception(s) associated with G-CS-RNTIs.
Note: If the UE receives two SPS PDSCH releases for two respective G-CS-RNTIs with DAI=1, or two PDSCHs by DCI 4_1 with DAI=1 for two respective G-RNTIs on the PCell, there is no fallback.
R1-2202579 FL summary#4 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
From Mar 2nd GTW session
Agreement
For Type-1 codebook generation, if all configured G-RNTIs are with HARQ-ACK disabled by RRC signalling, UE does not report any HARQ-ACK information in the PUCCH slot;
· For other cases, FFS between the 3 alternatives below:
o Alt1: if at least one configured G-RNTI is with HARQ-ACK enabled, UE will report NACK for the G-RNTI with HARQ-ACK disabled regardless of decoding results of corresponding PDSCH.
o Alt2: if at least one configured G-RNTI is with HARQ-ACK enabled, UE reports actual HARQ-ACK result for all G-RNTIs.
o Alt3: UE is not expected to be configured with some G-RNTI with HARQ-ACK disabled by RRC signalling and some other G-RNTI with HARQ-ACK enabled by RRC signalling for all configured G-RNTI
o Other alternatives are not precluded
Decision: As per email decision posted on Mar 3rd,
Agreement
· Text Proposal 4.2.2-1 (for TS 38.213 clause 9.2.3) in section 12 of R1-2202579 is endorsed.
· Text Proposal 4.2.2-2 (for TS 38.213 clause 9.1.2.1) in section 12 of R1-2202579 is endorsed.
· Text Proposal 5.1.1 (for TS 38.213 clause 18) in section 12 of R1-2202579 is endorsed.
R1-2202883 FL summary#5 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
From Mar 3rd GTW session
Agreement
If Type-2 codebook is configured for unicast and multicast, the following option2-2 (from the previous agreement) is adopted:
· Option2-2: 2-bit UL DAI(s) are included in DCI for multicast, in addition to the 2-bit UL DAI for unicast.
o The 2-bit UL DAI for multicast is applied for all configured G-RNTIs.
§ FFS: how to count the total number of HARQ-ACK bits for all configured G-RNTIs.
· Alt1-1: UL-DAI indicates the sum of DL-DAIs
· Alt1-2: DL-DAIs have the same value.
· Alt1-3: largest DL DAI value among the configured G-RNTIs.
· Other alternatives are not precluded
Agreement
When Type-1 codebook is configured for unicast and Type-2 codebook is configured for multicast, or when Type-2 codebook is configured for unicast and Type-1 codebook is configured for multicast, the UL-DAI for multicast is included in DCI format 0_1/0_2, in addition to the UL-DAI field for unicast.
· The UL-DAI for multicast is 1-bit for Type-1 codebook
o The 1-bit UL-DAI for multicast is applied to all configured G-RNTIs.
· The UL-DAI for multicast is 2-bit for Type-2 codebook applied for all configured G-RNTIs.
o FFS: how to count the total number of HARQ-ACK bits for all configured G-RNTIs.
§ Alt1-1: UL-DAI indicates the sum of DL-DAIs
§ Alt1-2: DL-DAIs have the same value.
§ Alt1-3: largest DL DAI value among the configured G-RNTIs.
§ Other alternatives are not precluded
· FFS: details of the UL DAI field
Decision: As per email decision posted on Mar 3rd,
Agreement
For NACK-only feedback for PUCCH format 0 or format 1, only 1 cyclic shift is used.
·
The sequence cyclic shift
for NACK-only is 
.
·
For PF1 NACK-only, set 
.
· Note: the initialCyclicShift is configured for PUCCH-format0 and PUCCH-format1 as legacy.
Agreement
For multiplexing NACK-only with HARQ-ACK feedback/CSI for unicast for the same priority or PUSCH transmission for the same priority or ACK/NACK based HARQ-ACK feedback for multicast with another G-RNTI for the same priority, the multiplexing does not depend on the decoding result.
· Note: when multiplexing the NACK-only is transformed into ACK/NACK as agreed.
Agreement
For Type-2 codebook generation, UE reports HARQ-ACK bits only for TBs with enabled HARQ-ACK by RRC or DCI.
Agreement
For multiplexing NACK-only feedback for the first G-RNTI with ACK/NACK based feedback for the second G-RNTI or for unicast, the following Alt2 (from the previous agreement) is adopted:
· Alt1: the converted NACK-only bits are concatenated to the ACK/NACK feedback.
· Alt2: the codebook construction/concatenation is the same as when the feedback mode is ‘ACK/NACK’ for both G-RNTIs.
Agreement
If a UE supports ACK/NACK based feedback for dynamic multicast scheduling and for multicast SPS, and if the UE is configured with ACK/NACK based feedback for multicast dynamic scheduling and is configured with disabled HARQ feedback for multicast SPS scheduling, for Type-1 codebook generation,
·
FFS between the 3 4 alternatives below:
o Alt1: UE will report NACK for the G-CS-RNTI with HARQ-ACK disabled regardless of decoding results of corresponding PDSCH.
o Alt2: UE will report ACK/NACK for the G-CS-RNTI with HARQ-ACK disabled regardless of decoding results of corresponding PDSCH.
o Alt3: UE is not expected to be configured with G-RNTI with HARQ-ACK enabled by RRC signalling and G-CS-RNTI with HARQ-ACK enabled by RRC signalling.
o Alt4: UE does not report any HARQ-ACK information for G-CS-RNTI with HARQ-ACK feedback disabled by RRC.
o Other alternatives are not precluded.
R1-2200950 Discussion on UE receiving broadcast in RRC IDLE/INACTIVE state Huawei, HiSilicon
R1-2201008 Remaining Issues on Broadcast / Multicast for RRC_IDLE / RRC_INACTIVE UEs Nokia, Nokia Shanghai Bell
R1-2201116 Remaining issues on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs vivo
R1-2201172 Maintenance of Functions for Broadcast or Multicast for RRC_IDLE or RRC_INACTIVE UEs ZTE
R1-2201259 Discussion on remaining issues of basic functions for RRC_IDLE/RRC_INACTIVE UEs OPPO
R1-2201340 Remaining issues on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs CATT
R1-2201498 Remaining issues on basic functions for broadcast NTT DOCOMO, INC.
R1-2201597 Discussion on basic functions for broadcast mode TD Tech, Chengdu TD Tech
R1-2201719 Broadcast for RRC_IDLE/INACTIVE UEs Intel Corporation
R1-2201788 Remaining issues on MBS for RRC_IDLE/RRC_INACTIVE UEs Apple
R1-2201817 Basic Functions for Broadcast or Multicast for RRC_IDLE or RRC_INACTIVE UEs Spreadtrum Communications
R1-2201878 Remaining issues on NR MBS in RRC_IDLE/RRC_INACTIVE states CMCC
R1-2201932 Remaining issues on broadcast and multicast for RRC_IDLERRC_INACTIVE UEs Xiaomi
R1-2202036 Maintenance on broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs Samsung
R1-2202081 Remaining issues on MBS broadcast reception for RRC_IDLE and INACTIVE UEs MediaTek Inc.
R1-2202162 Maintenance on group scheduling for Broadcast RRC_IDLE/INACTIVE UEs Qualcomm Incorporated
R1-2202229 Remaining issues on basic functions for broadcast/multicast in idle/inactive states Lenovo, Motorola Mobility
R1-2202351 Basic function for broadcast/multicast LG Electronics
R1-2202398 Support for NR multicast reception in RRC Inactive/Idle Ericsson
[108-e-R17-MBS-03] – David (BBC)
Email discussion/approval on basic functions for broadcast/multicast for RRC_IDLE/RRC_INACTIVE UEs
- 1st check point: February 25
- Final check point: March 3
R1-2202548 Feature Lead summary #1 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/RRC_INACTIVE states Moderator (BBC)
From Feb 22nd GTW session
Agreement
In the reply LS on MBS issues to RAN2, capture the following:
· RAN1 confirm RAN2’s understanding that only a single frequency resource in CFR (indicated by locationAndBandwidth-Broadcast) is configured for MCCH/MTCH reception of MBS broadcast and it is common for MCCH and all MTCHs.
Draft reply LS to
R1-2200882 LS on MBS issues RAN2, Huawei
R1-2202610 DRAFT LS reply about the MBS issues Moderator (Huawei)
Decision: As per email decision posted on Feb 25th, the draft LS is endorsed. Final LS is approved in R1-2202611.
Agreement
RateMatchPatternLTE-CRS can be configured in PDSCH-Config-MCCH or PDSCH-Config-MTCH for RRC_IDLE/RRC_INACTIVE UEs.
Agreement
For broadcast reception, if the frequency resources of the CFR for broadcast is larger than CORESET0, a CORESET larger than CORESET0 can be configured in the CFR when no CORESET is configured by commonControlResourceSet.
R1-2202549 Feature Lead summary #2 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/RRC_INACTIVE states Moderator (BBC)
Decision: As per email decision posted on Feb 26th,
Agreement
· TP-2.3-1 (for Section 5.1.2.1 of TS38.214) in section 6 of R1-2202549 is endorsed.
· TP-2.4-2 (for Section 10.1 of TS 38.213) in section 6 of R1-2202549 is endorsed.
· TP-2.4-4 (for Section 18 of TS 38.213) in section 6 of R1-2202549 is endorsed.
R1-2202550 Feature Lead summary #3 on RAN basic functions for broadcast/multicast for UEs in RRC_IDLE/RRC_INACTIVE states Moderator (BBC)
Decision: As per email decision posted on Mar 2nd,
Agreement
For RRC_IDLE/INACTIVE UEs, a UE is required to support reception of FDMed MCCH PDSCH and PBCH in PCell.
Agreement
For RRC_IDLE/INACTIVE UEs, a UE is not required to support reception of FDMed MTCH PDSCH and PBCH in PCell.
Agreement
· TP-2.4-3 (for Section 18 of TS 38.213) in section 6 of R1-2202550 is endorsed.
Final summary in R1-2202817.
R1-2201117 Other issues for Rel-17 MBS vivo
R1-2201173 Discussion on RRC parameters of Rel-17 MBS ZTE
R1-2201341 Discussion on other issues in Rel-17 MBS CATT
R1-2201598 Discussion on typical configuration for broadcast mode TD Tech, Chengdu TD Tech
R1-2201609 Discussion on further improvements for MBS ASUSTeK
R1-2201933 Other remaining issues for MBS Xiaomi
R1-2202352 Other aspects for MBS LG Electronics
R1-2202399 Assumptions for performance evaluations of NR-MBS Ericsson
R1-2202432 Views on overall configurations for multicast Huawei, HiSilicon
R1-2205569 Session notes for 8.12 (Maintenance on NR Multicast and Broadcast Services) Ad-Hoc Chair (Huawei)
R1-2205129 Moderator summary for preparation phase on maintenance of Rel-17 WI on NR MBS Moderator (CMCC)
R1-2203044 LS on HARQ process for MCCH and Broadcast MTCH(s) RAN2, Samsung
[109-e-R17-MBS-01] – David (BBC)
Email discussion on LS in R1-2203044 until May 12
R1-2205213 Feature lead summary #1 on discussion of RAN2 LS on HARQ process for MCCH and Broadcast MTCH(s) Moderator (BBC)
From May 13th GTW session
Proposal 2.1rev2a: In the reply LS on HARQ process for MCCH and Broadcast MTCH(s) to RAN2, capture the following:
· From RAN1 perspective:
o from network perspective, UE can be assumed the following can be assumed:
§ to be able to use a single HARQ process for MCCH and single HARQ process for MTCH(s).
§ to be able to use the same HARQ process MCCH and MTCH(s) .
o from UE perspective, it is up to the UE’s implementation whether the HARQ process for MCCH and the HARQ process for MTCH is the same or different.
Proposal (Alt 2)
· From RAN1 perspective:
o from UE perspective, it is up to the UE’s implementation whether the HARQ process for MCCH and the HARQ process for MTCH is the same or different.
Proposal (Alt 3)
· From RAN1 perspective:
o A UE is expected to be able to receive MCCH
and MTCH(s) using in total a single HARQ process when the UE is
receiving unicast/multicast using 15 HARQ processes
o from UE perspective, it is up to the UE’s implementation whether the HARQ process for MCCH and the HARQ process for MTCH is the same or different.
R1-2205334 Feature lead summary #2 on discussion of RAN2 LS on HARQ process for MCCH and Broadcast MTCH(s) Moderator (BBC)
Decision: As per email decision posted on May 17th,
Agreement
In the reply LS on HARQ process for MCCH and Broadcast MTCH(s) to RAN2, capture the following (Proposal 2.1rev3a in R1-2205334):
· From RAN1 perspective:
o It is up to the UE’s implementation whether the HARQ process for MCCH and the HARQ process for MTCH is the same or different.
o UEs in RRC_CONNECTED can use at least one HARQ process to receive MCCH and broadcast MTCH(s).
R1-2205418 DRAFT Reply LS on HARQ process for MCCH and Broadcast MTCH(s) BBC (rev of R1-2205214)
Decision: As per email decision posted on May 17th, the draft LS is endorsed. Final LS is approved in R2-2205215.
Final summary in R1-2205426.
R1-2204892 Text proposal to TS 38.300 on NR MBS Huawei, HiSilicon, CBN
[109-e-R17-MBS-02] – Jinhuan (Huawei)
Email discussion on NR MBS TP for TS38.300 (R1-2204892) until May 12
R1-2205158 FL summary#1 for discussion on NR MBS TP for TS38.300 Moderator (Huawei)
Decision: As per email decision posted on May 13th,
· TP for TS38.300 in section 3 of R1-2205158 is endorsed and will be provided in an LS to RAN2.
R1-2205335 [Draft] LS on NR MBS TP for TS 38.300 Huawei
Decision: As per email decision posted on May 13th, the draft LS is endorsed. Final LS is approved in R1-2205336.
R1-2203070 Mechanisms to improve reliability for RRC_CONNECTED UEs Huawei, HiSilicon, CBN
R1-2203194 Maintenance of reliability improvement for MBS ZTE
R1-2203227 Open issues on reliability for NR MBS TD Tech Ltd
R1-2203287 Remaining Issues on Reliability Improvements for RRC_CONNECTED UEs supporting MBS Nokia, Nokia Shanghai Bell
R1-2203314 Discussion on the remaining issues on mechanisms to improve MBS reliability for RRC_CONNECTED UEs Spreadtrum Communications
R1-2203427 Remaining issues on reliability improvement mechanism for RRC_CONNECTED UEs in MBS CATT
R1-2203526 Remaining issues on mechanisms to improve reliability for RRC_CONNECTED UEs vivo
R1-2203613 Remaining issues on mechanisms to improve reliability for MBS ETRI
R1-2203677 Remaining Issues on Reliability Improvements for RRC_CONNECTED UEs NEC
R1-2203699 Remaining issues on reliability improvement for RRC-CONNECTED UEs Lenovo
R1-2203838 Remaining issues on mechanisms to improve reliability for RRC_CONNECTED UEs Langbo
R1-2203874 Maintenance on mechanisms to improve reliability Samsung
R1-2203974 Discussion on remaining issues of mechanism to improve reliability for RRC_CONNECTED UEs OPPO
R1-2204216 Remaining issues on MBS reliability improvement for RRC_connected UEs Apple
R1-2204282 Maintenance on mechanisms to improve reliability for RRC_CONNECTED UEs CMCC
R1-2204354 Remaining issues on HARQ-ACK feedback procedure for multicast NTT DOCOMO, INC.
R1-2204502 Remaining reliability issues of MBS for RRC_CONNECTED UEs Google Inc.
R1-2204622 Mechanisms to improve reliability of Broadcast/Multicast service LG Electronics
R1-2204717 Remaining issues on improve multicast reliability for RRC_CONNECTED UEs MediaTek Inc.
R1-2204945 Remaining issues for improvement of reliability of NR MBS Ericsson
R1-2204994 Mechanisms to improve reliability for RRC_CONNECTED UEs Qualcomm Incorporated
[109-e-R17-MBS-03] – Jinhuan (Huawei)
Email discussion/approval for maintenance on mechanisms to improve reliability for RRC_CONNECTED UEs, for issues #1-1, 1-2, 1-3, 1-4, 1-11, 1-12, 1-13, 1-14, 1-15 in R1-2205129
- 1st check point: May 13 (any RRC impact by May 12)
- Final check point: May 18
R1-2205155 FL summary#1 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
From May 11th GTW session
Agreement
For the 2-bit UL-DAI for multicast indicating the total number of Type-2 HARQ-ACK bits multiplexed in PUSCH, UE generates the Type-2 HARQ-ACK sub-codebook for each G-RNTI per the UL-DAI and concatenates all the sub-codebooks in the ascending order of G-RNTI value.
·
If the 2-bit UL-DAI field
for multicast has the value of 
and the UE has not received any PDCCH within the monitoring
occasions with DCI format 4_1/4_2, the UE does not multiplex HARQ-ACK
information for multicast feedback in the PUSCH transmission.
Agreement
When UE is configured with multiple cells for unicast and Type-1 codebook is configured for both multicast and unicast,
· if the UE is configured to construct the HARQ-ACK codebooks for unicast and multicast jointly, a single UL DAI bit applies for unicast and multicast;
· Otherwise, 1 additional bit UL DAI is included for multicast in DCI format 0_1/0_2, in addition to the UL DAI for unicast. The 1-bit UL DAI for multicast is applied to all configured G-RNTIs.
Agreement
For UE configured with NACK-only HARQ-ACK feedback, for Alt4 (from previous agreement), define the mapping between HARQ-ACK values and the PUCCH resources for the TBs configured with NACK-only as follows:
· The mapping is applied to both a single G-RNTI
o FFS: multiple configured G-RNTIs cases.
· FFS: how to order the TBs, whether/how to account for missed or non-scheduled TBs
· FFS whether/how PRI is used for indication.
|
HARQ-ACK Value |
PUCCH resource |
|||
|
{0} |
{0,0} |
{0,0,0} |
{0,0,0,0} |
1st PUCCH resource provided by pucch-ResourceId obtained from the 1st value of resourceList |
|
{1,0} |
{1,0,0} |
{1,0,0,0} |
2nd PUCCH resource provided by pucch-ResourceId obtained from the 2nd value of resourceList |
|
|
{0,1} |
{0,1,0} |
{0,1,0,0} |
3rd PUCCH resource provided by pucch-ResourceId obtained from the 3rd value of resourceList |
|
|
{1,1,0} |
{1,1,0,0} |
4th PUCCH resource provided by pucch-ResourceId obtained from the 4th value of resourceList |
||
|
{0,0,1} |
{0,0,1,0} |
5th PUCCH resource provided by pucch-ResourceId obtained from the 5th value of resourceList |
||
|
{1,0,1} |
{1,0,1,0} |
6th PUCCH resource provided by pucch-ResourceId obtained from the 6th value of resourceList |
||
|
{0,1,1} |
{0,1,1,0} |
7th PUCCH resource provided by pucch-ResourceId obtained from the 7th value of resourceList |
||
|
{1,1,1,0} |
8th PUCCH resource provided by pucch-ResourceId obtained from the 8th value of resourceList |
|||
|
{0,0,0,1} |
9th PUCCH resource provided by pucch-ResourceId obtained from the 9th value of resourceList |
|||
|
{1,0,0,1} |
10th PUCCH resource provided by pucch-ResourceId obtained from the 10th value of resourceList |
|||
|
{0,1,0,1} |
11th PUCCH resource provided by pucch-ResourceId obtained from the 11th value of resourceList |
|||
|
{1,1,0,1} |
12th PUCCH resource provided by pucch-ResourceId obtained from the 12th value of resourceList |
|||
|
{0,0,1,1} |
13th PUCCH resource provided by pucch-ResourceId obtained from the 13th value of resourceList |
|||
|
{1,0,1,1} |
14th PUCCH resource provided by pucch-ResourceId obtained from the 14th value of resourceList |
|||
|
{0,1,1,1} |
15th PUCCH resource provided by pucch-ResourceId obtained from the 15th value of resourceList |
|||
Agreement
·
For power determination of
a PUCCH transmission for the “NACK-only” reporting mode in clause 7.2.1 in TS
38.213, 
.
Agreement
·
For power determination of
a PUCCH transmission with multicast HARQ-ACK mode in clause 7.2.1 in TS 38.213,
a UE with two CLPC adjustment states applies the one corresponding to 
.
R1-2205156 FL summary#2 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
From May 16th GTW session
Agreement
For multicast, for addressing how to count and order the HARQ-ACK bits for NACK-only for Alt4:
· Case 1: when the HARQ-ACK-to-PUCCH mapping table for Alt4 (from previous agreement) is applied to a single G-RNTI (from network and UE perspective)
o Opt1-1: based on C-DAI included in DL DCI for counting the number of HARQ-ACK bits and for ordering the HARQ-ACK bits.
- FFS: whether Opt1-1 can also work when different G-RNTIs are used for different UEs
· Note: other cases are not precluded
R1-2205157 FL summary#3 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
Decision: As per email decision posted on May 19th,
Agreement
· For the case when the PUCCH transmission for the NACK-only based feedback for one G-RNTI collides with the PUCCH transmission for ACK/NACK feedback for another G-RNTI with the same priority and then UE multiplexes the NACK-only based feedback with the ACK/NACK feedback onto the same PUCCH by transforming NACK-only into the ACK/NACK based HARQ-ACK bit, the PUCCH resources for transmitting the multiplexed HARQ-ACK bits is from the PUCCH-Config/PUCCH-ConfigurationList configured for multicast with ACK/NACK based feedback.
· For a UE configured with G-RNTI(s) with NACK-only HARQ-ACK feedback, when NACK-only HARQ-ACK bits are transformed into ACK/NACK HARQ-ACK bits, the PUCCH resource used for transmitting the multiplexed HARQ-ACK bits is determined from PUCCH-Config/PUCCH-ConfigurationList configured for multicast with ACK/NACK based feedback based on the k1 and the PRI indication in the last DCI scheduling multicast. If PUCCH-Config/PUCCH-ConfigurationList configured for multicast with ACK/NACK based feedback is not configured, the PUCCH-Config/PUCCH-ConfigurationList configured for unicast is used.
o FFS: the case NACK-only is for multicast SPS PDSCH only.
Agreement
When the nominal NACK-only PUCCH overlaps with other PUCCH/PUSCH transmission, NACK-only is transformed into ACK/NACK and multiplexed with other PUCCH/PUSCH transmission. Down-select from the following options for the nominal NACK-only PUCCH:
· Opt1: The nominal NACK-only PUCCH consists of all the symbols from PUCCHs of the NACK-only PUCCH resource set.
· Opt2: The nominal NACK-only PUCCH starts from the earliest starting symbol of PUCCHs in the NACK-only PUCCH resource set, and ends at the latest ending symbol of PUCCHs in the set.
· Opt3: The nominal NACK-only PUCCH consists of all the symbols of the PUCCH slot.
· Opt4: All PUCCHs have the same starting symbol and the same time duration
· Other options are not precluded, e.g. based on PRI, or based on the number of TBs that will be transmitted in the PUCCH slot
· Note1: The terminology of the “nominal NACK-only PUCCH” is used for facilitate describing the issue. Up to editor for the specification impact.
· Note2: The following factors can be considered for down-selection:
o Up to 12 initial cyclic shifts can be configured to PF0. Up to 12 initial cyclic shifts and up to 7 time domain OCC can be configured to PF1.
o Up to 32 PUCCHs resources in the resource set are configured for NACK-only.
o The PUCCH configuration for unicast will be used when the PUCCH is not configured for NACK-only.
Agreement
Regarding the PDSCH and/or PUCCH processing procedure timeline for NACK-only based feedback, further discuss on whether/how to extending the PDSCH and/or PUCCH processing procedure timeline.
· Note1: The current PDSCH processing procedure timeline defined in clause 5.3 TS38.214 is for ACK/NACK based feedback.
· Note2: For NACK-only based feedback for more than 1 TB, one possible issue is that the PUCCH resource for NACK-only can only be determined after obtaining the decoding result of all the related PDSCHs for the UE.
Agreement
For Type-1 codebook generation, if at least one configured G-RNTI is with HARQ-ACK enabled by RRC, it is up to UE to report NACK or ACK/NACK for the G-RNTI with HARQ-ACK disabled
· FFS whether UE needs to generate Type-1 CB, when UE does not detect any DCI for G-RNTI(s) with HARQ-ACK enabled when at least one configured G-RNTI is with HARQ-ACK enabled by RRC.
· For the PUCCH resource for the codebook transmission,
o Opt2: PUCCH resource/slot is based on last DCI for a G-RNTI with HARQ-ACK enabled
Agreement
Adopt the following text proposal to TS38.213 v17.1.0 clause 18:
· Reason for change
o Specification should be clear and accurate regarding the meaning of “other UCI” for UE multiplexing with NACK-only for multicast.
· Summary of change
o Clarify that “other UCI” includes HARQ-ACK information associated with multicast configured with the first HARQACK reporting mode, HARQ-ACK information associated with unicast DCI formats or CSI reports.
· Consequences if not approved
o UE behavior may not be determinable for multiplexing NACK-only if the meaning of “other UCI” is unclear from specification.
|
--------------------------------Text proposal to TS38.213 v17.1.0 Starts--------------------------- 18 Multicast Broadcast Services < Unchanged parts are omitted > If
a UE would multiplex HARQ-ACK information that the UE would provide according
to the second HARQ-ACK reporting mode with If a UE is provided multiple G-RNTIs or G-CS-RNTIs, a configuration for a HARQ-ACK codebook type applies to all G-RNTIs or G-CS-RNTIs. < Unchanged parts are omitted > --------------------------------Text proposal to TS38.213 v17.1.0 Ends----------------------------- |
Agreement
Adopt the following text proposal to TS38.213 v17.1.0 clause 18:
· Reason for change
o How UE multiplexes NACK-only HARQ-ACK feedback for multicast with only CSI reports is undefined from the latest version of TS 38.213.
· Summary of change
o Adding a sentence in clause 18 that “If the first PUCCH includes only CSI reports, the UE multiplexes the HARQ-ACK information as described in clause 9.2.5.2 for HARQ-ACK information that is in response to PDSCH reception without corresponding PDCCH”.
· Consequences if not approved
o UE behavior about multiplexing NACK-only HARQ-ACK feedback for multicast with CSI for unicast is unclear.
|
------------------------------Text proposal to TS38.213 v17.1.0 Starts--------------------------------- 18 Multicast Broadcast Services < Unchanged parts are omitted > If a UE would multiplex HARQ-ACK information that the UE would provide according to the second HARQ-ACK reporting mode with other UCI in a first PUCCH, or in a PUSCH, as described in clauses 9 and 9.2.5, the UE provides the HARQ-ACK information according to the first HARQ-ACK reporting mode. For resolving an overlapping among a second PUCCH with HARQ-ACK information according to the second HARQ-ACK reporting mode and other PUCCHs or PUSCHs prior to multiplexing the HARQ-ACK information in a PUCCH or PUSCH, the UE considers that the UE would transmit the second PUCCH when all values of the HARQ-ACK information are 'ACK'. If the first PUCCH includes only CSI reports, the UE multiplexes the HARQ-ACK information as described in clause 9.2.5.2 for HARQ-ACK information that is in response to PDSCH reception without corresponding PDCCH. If a UE is provided multiple G-RNTIs or G-CS-RNTIs, a configuration for a HARQ-ACK codebook type applies to all G-RNTIs or G-CS-RNTIs. < Unchanged parts are omitted > --------------------------------Text proposal to TS38.213 v17.1.0 Ends-------------------------------- |
Agreement
Adopt the following text proposal to TS38.213 v17.1.0 clause 18:
· Reason for change
o The latest version of TS38.213 V17.1.0 does not reflect the agreement correctly regarding how to support more than one TB with NACK-only feedback for multicast. In particular, when UE is configured with moreThanOneNackOnly-Mode indicating the HARQ-ACK information is transmitted according to the first HARQ-ACK report mode, the number of TBs with NACK-only can be any number not smaller than one and otherwise the number should be no more than four.
· Summary of change
o Deleting “when a number of HARQ-ACK information bits is more than four, or” and “when a number of HARQ-ACK information bits is 2, 3, or 4 more than one,”.
· Consequences if not approved
o NACK-only HARQ-ACK feedback for more than four TBs is not supported when UE is configured to transmit the PUCCH according to the first HARQ-ACK report mode.
|
--------------------------------Text proposal to TS38.213 v17.1.0 Starts---------------------------- 18 Multicast Broadcast Services < Unchanged parts are omitted > For
the second HARQ-ACK reporting mode, the UE does not transmit a PUCCH that
would include only HARQ-ACK information with ACK values. The second HARQ-ACK
reporting mode is not applicable For
the second HARQ-ACK reporting mode, when a number of HARQ-ACK information
bits is one, a UE transmits a PUCCH only when the HARQ-ACK information bit
has NACK value. For a PUCCH resource associated with PUCCH format 0, the UE
transmits the PUCCH as described in [4, TS 38.211] by obtaining For
the second HARQ-ACK reporting mode, If a UE is provided pucch-Config-Multicast1 or pucch-Config-Multicast2 for PUCCH transmissions with a priority value, the UE transmits a PUCCH with the priority value according to pucch-Config-Multicast1 or pucch-Config-Multicast2 for each G-RNTI or G-CS-RNTI that the UE provides associated HARQ-ACK < Unchanged parts are omitted > --------------------------------Text proposal to TS38.213 v17.1.0 Ends----------------------------- |
Agreement
When UE supports and is configured with more than one G-CS-RNTI, for TB retransmissions that are scheduled by G-CS-RNTI,
· for Type-2 codebook construction, DL-DAI is separately counted per G-CS-RNTI,
· Type-2 codebook is constructed by concatenating Type-2 sub-codebook of each G-CS-RNTI following the ascending order of the G-CS-RNTI value.
· Type-2 HARQ-ACK sub-codebook for G-CS-RNTIs is appended to the one for G-RNTI.
Decision: As per email decision posted on May 21st,
Agreement
For multicast, for addressing how to count and order the HARQ-ACK bits for NACK-only for Alt4, further down-selection on the following cases/options in the next meeting:
· Case 2: for the case of all UEs configured with the same set of G-RNTIs
o Opt2-1: support Alt4 for this case
§ Opt2-1-1: based on the sum of C-DAI included in the last scheduling DCI from each G-RNTI for counting the total number of HARQ-ACK bits. The ordering of HARQ-ACK bits is per C-DAI from each G-RNTI and in the ascending order of G-RNTI values.
§ Opt2-1-2: based on C-DAI* included in the last scheduling DCI for counting the number of HARQ-ACK bits and for ordering the HARQ-ACK bits. The C-DAI* is accumulating the scheduled TBs across different G-RNTIs
o Opt2-2: does not support Alt4 for this case.
· Case 3: for the case of different UEs configured with different G-RNTIs
o Opt3-1: support Alt4 for this case
§ Opt3-1-1: based on the sum of C-DAI included in the last scheduling DCI from each G-RNTI for counting the total number of HARQ-ACK bits. The ordering of HARQ-ACK bits is per C-DAI from each G-RNTI and in the ascending order of G-RNTI values.
§ Opt3-1-2: based on C-DAI* included in the last scheduling DCI for counting the number of HARQ-ACK bits and for ordering the HARQ-ACK bits. The C-DAI* is accumulating the scheduled TBs across different G-RNTIs.
o Opt3-2: does not support Alt4 for this case.
Final summary in R1-2205550.
For any other maintenance issues on NR Multicast and Broadcast Services
R1-2203195 Maintenance of other issues for broadcast and multicast ZTE
R1-2203228 Discussion on typical configuration for broadcast mode TD Tech Ltd (Withdrawn)
R1-2203288 Remaining Issues for NR MBS Nokia, Nokia Shanghai Bell
R1-2203315 Discussion on the remaining issues for MBS Spreadtrum Communications
R1-2203527 Maintenance on NR Multicast and Broadcast Services vivo
R1-2203700 Remaining issues on group scheduling mechanism for RRC_CONNECTED UEs Lenovo
R1-2203776 Other remaining issues for multicast and broadcast xiaomi
R1-2203875 Maintenance on group scheduling for RRC_CONNECTED UEs Samsung
R1-2204189 Discussion on MBS SPS activation validation ASUSTeK
R1-2204283 Maintenance on group scheduling mechanisms for NR multicast and broadcast services CMCC
R1-2204355 Remaining issues on group scheduling mechanisms for MBS NTT DOCOMO, INC.
R1-2204623 Other remaining issues for MBS LG Electronics
R1-2204891 Remaining issues for multicast and broadcast scheduling Huawei, HiSilicon, CBN
R1-2204946 Remaining issues for group scheduling of NR MBS Ericsson
R1-2204995 Other remaining issues for Rel-17 MBS Qualcomm Incorporated
[109-e-R17-MBS-04] – Tuo (CMCC)
Email discussion for maintenance on mechanisms to support broadcast/multicast for RRC_CONNECTED/RRC_IDLE/RRC_INACTIVE UEs, for issues #2-1, 2-2/3-1, 2-3, 2-4, 2-5, 2-6/2-7, 2-12, 3-3, 2-23, 2-13/3-2 in R1-2205129
- 1st check point: May 13 (any RRC impact by May 12)
- Final check point: May 18
R1-2205169 Summary#1 on mechanisms to support broadcast/multicast for RRC_CONNECTED/RRC_IDLE/ RRC_INACTIVE UEs Moderator (CMCC)
From May 13th GTW session
Agreement
For RRC_CONNECTED UEs,
· a UE is not required to support reception of FDMed MCCH/MTCH/multicast PDSCH and SIB PDSCH in Pcell.
· a UE is required to support reception of FDMed MCCH PDSCH and PBCH in Pcell.
· a UE is not required to support reception of FDMed MTCH PDSCH and PBCH in Pcell.
· a UE is not required to support reception of FDMed multicast PDSCH and PBCH in Pcell.
Agreement
For RRC_CONNECTED UEs,
· a UE is not required to support reception of FDMed multicast PDSCHs in Pcell or Scell.
· a UE is not required to support reception of FDMed multicast PDSCH and MCCH/MTCH for broadcast in Pcell or Scell.
· a UE is not required to support reception of FDMed multicast PDSCH and Paging PDSCH in Pcell.
Decision: As per email decision posted on May 13th,
Agreement
· Text Proposal 5-2-v3 (for 38.214 v17.1.0, clause 5.1.5) in section 5 of R1-2205169 is endorsed.
· Send a LS to RAN2 to inform that parameter tci-PresentInDCI is also used to indicate if TCI field is present or absent in DCI format 4_2. (approved on May 17th, see below)
Agreement
For RRC_IDLE/INACTIVE UEs, a UE is not required to support reception of FDMed MCCH/MTCH PDSCH and RAR PDSCH in PCell.
Agreement
For RRC_CONNECTED UEs,
· a UE is not required to support reception of FDMed MCCH PDSCH and MTCH PDSCH in PCell or SCell.
· a UE is not required to support reception of FDMed multiple MTCH PDSCHs in PCell or SCell.
Agreement
For RRC_CONNECTED UEs, a UE is not required to support reception of FDMed MCCH/MTCH/multicast PDSCH and RAR PDSCH in PCell.
Agreement
· Text Proposal 4-1-v2 (for 38.214 v17.1.0, clause 5.1.4.2) in section 5 of R1-2205169 is endorsed.
· Text Proposal 4-2-v2 (for 38.214 v17.1.0, clause 5.1.4.2) in section 5 of R1-2205169 is endorsed.
· Text Proposal 4-3-v2 (for 38.214 v17.1.0, clause 5.1.4.2) in section 5 of R1-2205169 is endorsed.
· Text Proposal 4-4-v2 (for 38.214 v17.1.0, clause 5.1.4.1) in section 5 of R1-2205169 is endorsed.
· Text Proposal 5-1-v2 (for 38.214 v17.1.0, clause 5.1.3.2) in section 5 of R1-2205169 is endorsed.
Agreement
For PTM based SPS PDSCH retransmission, the repetition number is determined by pdsch-AggregationFactor in SPS-Config-Multicast.
Agreement
· Text Proposal 3-3-1-v2 (for 38.214 v17.1.0, clause 5.1.4.1) in section 5 of R1-2205169 is endorsed.
·
Text Proposal 8-2-v2 (for 38.213 v17.1.0,
clause 10.1) in section 5 of R1-2205169
is endorsed. (Note)
· Text Proposal 9-1-v2 (for 38.213 v17.1.0, clause 10.1) in section 5 of R1-2205169 is endorsed.
Note: TP 8-2-v2 already exists in v17.1.0 (proposed TP based on early v17.0.0).
R1-2205368 Draft LS on TCI indication in multicast DCI Moderator (CMCC)
Decision: As per email decision posted on May 17th, the draft LS is endorsed. Final version is approved in 1-2205369.
R1-2205170 Summary#2 on mechanisms to support broadcast/multicast for RRC_CONNECTED/RRC_IDLE/ RRC_INACTIVE UEs Moderator (CMCC)
Decision: As per email decision posted on May 21st,
For the FDMed or TDMed unicast PDSCH and group-common PDSCH capability of RRC_CONNECTED UE, the group-common PDSCH can be multicast group-common PDSCH or broadcast group-common PDSCH.
· FFS single or separate UE capability for multicast and broadcast for intra-slot TDM unicast PDSCH and group-common PDSCH
· Note 1: For the TDMed case, the maximum number of TDMed PDSCH receptions capability in a slot per CC is kept as for Rel-15/Rel-16
· Note 2: For the FDMed case, only one unicast PDSCH and one group common PDSCH in a slot per CC is supported
Conclusion
For FDM between one unicast PDSCH and one group-common PDSCH in a slot, only case 1 in the following cases is supported.
· Case 1: the unicast PDSCH and the group-common PDSCH in a slot are partially or fully overlapping in time domain and non-overlapping in frequency domain
· Case 2: the unicast PDSCH and the group-common PDSCH in a slot are non-overlapping in time domain and non-overlapping in frequency domain
· Case 3: the unicast PDSCH and the group-common PDSCH in a slot are non-overlapping in time domain and overlapping in frequency domain
Final summary in R1-2205171.
R1-2208142 Session notes for 8.12 (Maintenance on NR Multicast and Broadcast Services) Ad-Hoc Chair (Huawei)
[110-R17-MBS] Email to be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc – Jinhuan (Huawei)
R1-2205757 Remaining issues for Rel-17 NR MBS Huawei, HiSilicon, CBN
R1-2205951 Maintenance of broadcast and multicast for MBS ZTE
R1-2205978 Discussion on the remaining issues for MBS Spreadtrum Communications
R1-2206102 Remaining issues on mechanisms to improve reliability for RRC_CONNECTED UEs Langbo
R1-2206285 Discussion on remaining issues on NR MBS OPPO
R1-2206361 Maintenance on NR Multicast and Broadcast Services CATT
R1-2206445 Remaining Issues for RRC_CONNECTED UEs supporting MBS Nokia, Nokia Shanghai Bell
R1-2206446 Remaining issues on reliability improvement and group scheduling for MBS Lenovo
R1-2206476 Remaining Issues on Reliability Improvements for RRC_CONNECTED UEs NEC
R1-2206611 Text proposals for NR Multicast and Broadcast Service Xiaomi
R1-2206764 Maintenance on NR Multicast and Broadcast Services vivo
R1-2206805 Maintenance on multicast-broadcast services Samsung
R1-2206891 Maintenance on NR multicast and broadcast services CMCC
R1-2206946 Remaining issues on NR Multicast and Broadcast Services ETRI
R1-2207013 Remaining issues on NR MBS MediaTek Inc.
R1-2207034 Maintenance on NR Multicast and Broadcast Services LG Electronics
R1-2207207 Maintenance on Rel-17 NR multicast Qualcomm Incorporated
R1-2207314 Remaining issues on NR Multicast and Broadcast Services Apple
R1-2207387 Maintenance on NR multicast and broadcast services NTT DOCOMO, INC.
R1-2207503 Correction on MBS SPS ASUSTeK
R1-2207616 Maintenance on NR Multicast and Broadcast Services Ericsson
From agenda 5
R1-2205732 LS on rate matching patterns and CORESET configuration for MBS RAN2, Huawei
R1-2207857 FL summary#1 on configurations for MBS regarding rate matching patterns and CORESET Moderator (Huawei)
R1-2207858 FL summary#2 on configurations for MBS regarding rate matching patterns and CORESET Moderator (Huawei)
R1-2207975 FL summary#3 on configurations for MBS regarding rate matching patterns and CORESET Moderator (Huawei)
Agreement
When UE is configured with the same RateMatchPatternId in both the CFR and in the associated BWP, it is expected to have the same set of RBs/REs indicated by the patterns for rate matching around. Otherwise, the different RateMatchPatternId will be configured in the CFR and in the associated BWP.
Agreement
For UE not supporting multipleCORESET in FR1, in order to receive MBS multicast in CFR within UE active BWP,
· if a CORESET is not configured within the PDCCH-ConfigMulticast, the other CORESET than CORESET0 configured within UE active BWP for scheduling unicast can also to be used for scheduling multicast, and the CORESET is expected to be included completely within the CFR and the parameters configured in the CORESET are expected to be supported by the UE for multicast.
R1-2208071 DRAFT reply LS on rate matching patterns and CORESET configuration for MBS Huawei
Decision: The draft LS in R1-2208071 is endorsed (with typo corrected: is à are, and deletion of “which may affect RAN2 specification”). Final LS is approved in R1-2208072.
R1-2207711 FL summary#1 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
R1-2207712 FL summary#2 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
When NACK-only PUCCH overlaps with other PUCCH/PUSCH transmission, NACK-only is transformed into ACK/NACK and multiplexed with other PUCCH/PUSCH transmission:
· Opt4: All PUCCHs have the same starting symbol and the same time duration
R1-2207713 FL summary#3 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
R1-2207714 FL summary#4 on improving reliability for MBS for RRC_CONNECTED UEs Moderator (Huawei)
Agreement
For PRI included in DCI format 4_1/4_2,
· if the G-RNTI is configured with NACK-only mode1, PRI indicates the PUCCH for the HARQ-ACK feedback including the case of one TB in scheduled.
· If the G-RNTI is configured with NACK-only mode2,
o FFS on whether/how to interpret the PRI.
Agreement
For Type-1 HARQ-ACK codebook multiplexing for dynamic multicast scheduling with multicast SPS, and if the UE is configured with HARQ-ACK enabled for multicast dynamic scheduling and is configured with disabled HARQ feedback for multicast SPS scheduling, it is up to UE to report NACK or ACK/NACK for the G-CS-RNTI with HARQ-ACK disabled.
Agreement
When UE does not detect any DCI for G-RNTI(s) with HARQ-ACK enabled when at least one configured G-RNTI is with HARQ-ACK enabled by RRC, UE does not need to generate the Type-1 HARQ-ACK codebook for PUCCH transmission.
· Whether there is any specification impact can be further discussed.
Agreement
· TP3.1-2 for TS 38.213 in section 4 of R1-2207714 is endorsed.
· TP3.1-4 for TS 38.213 in section 4 of R1-2207714 is endorsed.
Agreement
The following text proposals in section 4 of R1-2207714 are for editors’ information for the next update of the specifications:
· For TS38.212
o Proposal 3 in R1-2206285
· For TS38.213
o proposals 4/5/6/7 in R1-2206285
o proposals 4/5 in R1-2206611
o TP in section 2.2 for TS38.213 in R1-2206764
o TP4 in section 2.6 for TS38.213 in R1-2207207,
o TP3 in R1-2207503.
R1-2207817 Moderator’s summary on Rel-17 NR MBS maintenance: mechanisms to support broadcast/multicast Moderator (CMCC)
R1-2207991 Moderator’s summary#2 on Rel-17 NR MBS maintenance: mechanisms to support broadcast/multicast Moderator (CMCC)
Agreement
· TP1.5 to TS 38.214 section 5.1.2.1 in R1-2207991 is endorsed.
Agreement
· TP1.8 to TS 38.214 section 5.1.2.1 in R1-2207991 is endorsed.
Agreement
· TP2.3 to TS 38.212 section 7.3.1.5.2 in R1-2207991 is endorsed with correction of typo (CORESETE à CORESET).
Agreement
At least in case of no FDMed unicast and MBS PDSCHs, the max data rate and upper bound of TBS LBRM for allocated TB(s) in a 14 consecutive-symbol duration is based on the unicast parameters.
Agreement
The following text proposals are for editors’ information for the next update of the specifications:
· For TS 38.211:
o Proposal 1 in R1-2205978
· For TS 38.213:
o CR-1and CR-2 in R1-2206361
o Proposal 1 in R1-2206611
· For TS38.214:
o CR-5 and CR-7 in R1-2206361
o TP in section 2.4 in R1-2206764
Agreement
· TP1.3.1 to TS 38.214 section 5.1.4.1 in R1-2207991 is endorsed.
R1-2210687 Session notes for 8.12 (Maintenance on NR Multicast and Broadcast Services) Ad-Hoc Chair (Huawei)
[110bis-e-R17-MBS-01] – Jinhuan (Huawei)
Email discussion to determine maintenance issues to be handled in RAN1#110bis-e by October 12
- Additional email discussions will be set up once the maintenance issues for RAN1#110bis-e are determined
- Including discussion on R1-2208581 from agenda item 5
R1-2210371 FLS on the issues for NR MBS maintenance Moderator (Huawei)
Decision: As per email decision posted on Oct 11th,
Conclusion of [110bis-e-R17-MBS-01]:
For Rel-17 MBS HARQ maintenance, based on the issues described in R1-2210371:
· Discuss the following issues: 1-1, 1-2, 1-3, 1-4, 1-5, 1-6, 1-7 (including whether case 2 and case 3 with NACK-only mode2 is supported in Rel-17), 1-8, 1-9, 1-10, 1-11, 1-12, 1-21
· Discuss the following editorial/alignment issues for providing to spec editors: 1-14, 1-15,
· Discuss for clarification of the issue (potentially discuss CR at RAN1#111, or conclude at RAN1#110bis-e that the issue is not essential): 1-16, 1-17, 1-18, 1-19, 1-20
· Postponed: 1-13 to the next meeting
· The corresponding draft CRs are not pursued in Rel-17 maintenance for these issues: 1-22 (a potential conclusion is to be discussed at RAN1#110bis-e), 1-23, 1-24
For Rel-17 MBS scheduling maintenance, based on the issues described in R1-2210371:
· Discuss the following issues: 2-1, 2-2, 2-3, 2-4, 2-5, 2-6, 2-7 (including whether this is simply a spec alignment issue), 2-8, 2-9
· Discuss the following editorial/alignment issues for providing to spec editors: 2-11, 2-12, 2-13, 2-14, 2-15
· Discuss for clarification of the issue (potentially discuss CR at RAN1#111, or conclude at RAN1#110bis-e that the issue is not essential): 2-10, 2-16, 2-17
· Discuss whether LS reply to R1-2208581 is needed for issue 2-18
R1-2208466 Correction on processing timeline for NACK-only mode2 to TS38.214 Huawei, HiSilicon, CBN
R1-2208467 Correction on codebook type for NACK-only HARQ-ACK feedback to TS38.213 Huawei, HiSilicon, CBN
R1-2208468 Correction on PRI for NACK-only HARQ-ACK feedback to TS38.213 Huawei, HiSilicon, CBN
R1-2208469 Correction on UE behaviors of PDCCH monitoring for configured RM patterns to TS38.213 Huawei, HiSilicon, CBN
R1-2208470 Correction on SS0 availability for scheduling MBS to TS38.213 Huawei, HiSilicon, CBN
R1-2208617 Draft CR on HARQ-ACK feedback for PDSCH scheduled by DCI format 4-1 vivo
R1-2208618 Draft CR on PUCCH determination for UE configured with NACK-only feedback mode vivo
R1-2208619 Draft CR on type 2 codebook determination with DG PDSCHs and SPS PDSCHs vivo
R1-2208620 Discussion on SPS PDSCH overlapping handling in FDM case vivo
R1-2208701 Remaining Issues for RRC_CONNECTED UEs supporting MBS Nokia, Nokia Shanghai Bell
R1-2208887 Draft CR on HARQ-ACK multiplexing of unicast SPS PDSCHs and multicast DG PDSCHs vivo
R1-2208923 Discussion on MBS supporting HARQ-ACK codebook retransmission CATT
R1-2208924 Discussion on MBS supporting deferring HARQ-ACK for SPS PDSCH CATT
R1-2208925 Draft CR on MBS supporting HARQ-ACK codebook retransmission CATT
R1-2208926 Draft CR on MBS supporting deferring HARQ-ACK for SPS PDSCH CATT
R1-2208927 Draft CRs for NR Multicast and Broadcast Service CATT
R1-2208928 Corrections on multicast DCI format to enable/disable HARQ-ACK CATT
R1-2208929 Discussion on multicast DCI format to enable/disable HARQ-ACK CATT
R1-2208995 Correction on Type-2 HARQ-ACK codebook for MBS Langbo
R1-2208996 Correction on Type-3 HARQ-ACK codebook for MBS Langbo
R1-2209137 Remaining Issues on NR MBS NEC
R1-2209310 Remaining issues on HARQ-ACK feedback for multicast CMCC
R1-2209311 Discussion on specs alignment of PDSCH simultaneous reception for MBS CMCC
R1-2209312 Draft CR on multicast HARQ-ACK codebook type configuration in DCI formats CMCC
R1-2209313 Draft CR on multicast rate-matching pattern configuration CMCC
R1-2209314 Draft CR on SPS and dynamic scheduling PDSCH(s) collision for MBS CMCC
R1-2209449 Maintenance on NR Multicast and Broadcast Services LG Electronics
R1-2209470 Maintenance of broadcast and multicast for MBS ZTE
R1-2209471 Draft CR on CFR configuration for multicast ZTE
R1-2209472 Draft CR on terms of G-RNTI used for MTCH ZTE
R1-2209473 Draft CR on restrictions of simultaneous reception ZTE
R1-2209474 Draft CR on SPS collision handling ZTE
R1-2209475 Draft CR on 1 bit NACK-only feedback ZTE
R1-2209476 Draft CR on determining NACK-only PUCCH in NACK-only mode1 ZTE
R1-2209524 Corrections on the MBS reception type combinations in TS 38.202 MediaTek Inc.
R1-2209525 Corrections on the MBS in TS 38.213 MediaTek Inc.
R1-2209526 Corrections on the MBS in TS 38.214 MediaTek Inc.
R1-2209527 Remaining issues on NR MBS MediaTek Inc.
R1-2209566 Remaining issues on NR Multicast and Broadcast Services Apple
R1-2209708 Maintenance on multicast-broadcast services Samsung
R1-2209822 Remaining issues for Rel-17 MBS Huawei, HiSilicon, CBN
R1-2209832 Correction on processing timeline for NACK-only mode2 to TS38.213 Huawei, HiSilicon, CBN
R1-2209833 Correction on the max data rate for multiplexing MBS and unicast to TS38.214 Huawei, HiSilicon, CBN
R1-2209882 Draft CR on DAI field in DCI format 4_2 NTT DOCOMO, INC.
R1-2209883 Draft CR on HARQ-ACK feedback for SPS GC-PDSCH NTT DOCOMO, INC.
R1-2209884 Draft CR on NACK-only based feedback for multicast NTT DOCOMO, INC.
R1-2209885 Draft CR on multiplexing NACK-only based feedback with SR NTT DOCOMO, INC.
R1-2209954 Draft CR on DCI-indicated enabling/disabling multicast feedback for Type-1 CB Qualcomm Incorporated
R1-2209955 Draft CR on Type-2 CB for NACK-only multicast feedback Qualcomm Incorporated
R1-2209956 Draft CR on max data rate per CC in case of FDMed unicast and MBS PDSCHs Qualcomm Incorporated
R1-2209957 Scaling factor for FDMed unicast and MBS PDSCHs Qualcomm Incorporated
R1-2209958 Draft CR on upper bound of TBS LBRM in case of FDMed unicast and MBS PDSCHs Qualcomm Incorporated
R1-2209959 Draft CR on PDSCH processing time required to select PUCCH for NACK-only mode2 based multicast feedback Qualcomm Incorporated
R1-2209960 Draft CR on multicast PDSCH with a HARQ process with disabled HARQ-ACK feedback Qualcomm Incorporated
R1-2209961 Draft CR on PDCCH monitoring when overlapping with rate matching patterns Qualcomm Incorporated
R1-2210075 Correction on MBS SPS ASUSTeK
R1-2210095 Correction on configurations of G-RNTI and G-CS-RNTI ASUSTeK
R1-2210096 Correction on configuration of PDSCH aggregation factor for MBS ASUSTeK
R1-2210155 Correction on HARQ-ACK codebook types in UL DCI formats for scheduling MBS Lenovo
R1-2210156 Draft CR on HARQ-ACK feedback for PDSCH scheduled by DCI format 4_1 Lenovo
R1-2210157 Draft CR on DAI update for multicast DCI formats Lenovo
R1-2210158 Draft CR on simultaneous configuration of Type-1 HARQ-ACK codebook and dci-enabler for multicast service Lenovo
R1-2210159 Remaining issues on HARQ-ACK feedback for NR MBS Lenovo
R1-2210173 Maintenance on NR Multicast and Broadcast Services Ericsson
R1-2210207 Correction on retransmission schemes for MBS HARQ-ACK feedback to TS38.213 Huawei, HiSilicon, CBN
R1-2210208 Correction on the channel combinations for MBS UE handling to TS38.213 Huawei, HiSilicon, CBN
R1-2210209 Correction on the channel combinations for MBS UE handling to TS38.214 Huawei, HiSilicon, CBN
R1-2210210 Correction on the channel combinations for MBS UE handling to TS38.202 Huawei, HiSilicon, CBN
[110bis-e-R17-MBS-02] – Jinhuan (Huawei)
Email discussion for maintenance on mechanisms to improve reliability for RRC_CONNECTED UEs for the following issues in R1-2210371
- Issues 1-1, 1-2, 1-3, 1-4, 1-5, 1-6, 1-7 (including whether case 2 and case 3 with NACK-only mode2 is supported in Rel-17), 1-8, 1-9, 1-10, 1-11, 1-12, 1-21
- Editorial/alignment issues for providing to spec editors: 1-14, 1-15
- Discuss for clarification of the issue (potentially discuss CR at RAN1#111, or conclude at RAN1#110bis-e that the issue is not essential): 1-16, 1-17, 1-18, 1-19, 1-20
- Discuss a potential conclusion (without CR) for issue 1-22
- Check points: October 14, October 19
R1-2210372 FLS#1 on the HARQ-ACK related issues for Rel-17 NR MBS Moderator (Huawei)
For issue 1-12 in R1-2210372
Agreement
For UEs not provided with SPS-PUCCH-AN-List, when UE would multiplex HARQ-ACK for unicast SPS PDSCHs and multicast dynamic grant PDSCHs, the PUCCH carrying the multiplexed HARQ-ACK is determined from PUCCH-Config/PUCCH-ConfigurationList configured for multicast.
Corresponding draft CR in:
R1-2210577 Draft CR on PUCCH resource determination for multiplexing dynamic multicast HARQ-ACK and SPS unicast HARQ-ACK Moderator (Huawei), vivo
Decision: As per email decision posted on Oct 11th, draft CR in R1-2210577 is endorsed in principle with the following revision:
• Adjust indentation for the sub-bullets needs (moved inwards – e.g. consistent with other indentation in 213)
Final CR is agreed in R1-2210729 (38.213, v17.3.0, Rel-17, CR#0401, Cat. F).
For issue 1-1 in R1-2210372
Agreement
For PRI included in DCI format 4_1/4_2, if the G-RNTI is configured with NACK-only mode2, PRI will be ignored by UEs.
Corresponding draft CR in:
R1-2210751 Draft CR on PRI for NACK-only HARQ-ACK feedback to TS38.213 Moderator (Huawei)
Decision: No consensus to endorse the draft CR, though the issue is considered as essential by a majority of companies. Draft CR is postponed to next meeting for finalization.
For issue 1-5 in R1-2210372
Agreement
For a UE configured with G-CS-RNTI(s) with NACK-only HARQ-ACK feedback, when NACK-only HARQ-ACK bits are transformed into ACK/NACK HARQ-ACK bits, the PUCCH resource used for transmitting the multiplexed HARQ-ACK bits is determined from the sps-PUCCH-AN-List configured for unicast, if sps-PUCCH-AN-ListMulticast is not configured.
Corresponding draft CR in:
R1-2210573 Draft CR on PUCCH resource determination of multicast HARQ-ACK Moderator (Huawei), Samsung
Decision: No consensus to endorse the draft CR, though the issue is considered as essential by a majority of companies. Draft CR is postponed to next meeting for finalization.
For issue 1-22 in R1-2210372
Agreement
It is up to UE implementation on which one to drop between SR or NACK-only when NACK-only collides with SR when UE would transmit PUCCH with HARQ-ACK according to the second reporting mode.
Corresponding draft CR in:
R1-2210638 Draft CR on handling SR and NACK-only collision Moderator (Huawei)
Agreement
The draft CR in R1-2210638 is endorsed in principle with the following revision:
·
If a UE would transmit a
first PUCCH with positive SR and a second PUCCH with HARQ-ACK information with
the same priority index according to the second HARQ-ACK reporting mode,
where the first and second PUCCHs would overlap in time in a slot and have same
priority index, it is up to UE implementation for the UE to transmit either the
first PUCCH or the second PUCCH.
Final CR is agreed in R1-2210730 (38.213, v17.3.0, Rel-17, CR#0402, Cat. F).
R1-2210373 FLS#2 on the HARQ-ACK related issues for Rel-17 NR MBS Moderator (Huawei)
For issue 1-2 in R1-2210373
Agreement
For UE provided NACK-only HARQ-ACK feedback for G-RNTI(s)/G-CS-RNTI(s), UE does not expect to be provided Type-1 HARQ-ACK codebook for multicast.
Corresponding draft CR in:
R1-2210571 Draft CR on codebook type for NACK-only HARQ-ACK feedback Moderator (Huawei)
Agreement
· The draft CR in R1-2210571 is endorsed. Final CR is agreed in R1-2210700 (38.213, v17.3.0, Rel-17, CR#0388, Cat. F).
For issue 1-3 in R1-2210373
Agreement
If a G-RNTI/G-CS-RNTI is configured with ‘dci-enabler’, the UE transmits the multicast feedback when scheduled by DCI format 4_1 for this G-RNTI/G-CS-RNTI.
• Inform RAN2 of the RAN1 agreement, with an action for RAN2 to check whether this impacts their specification and to let RAN2 update their specification if needed. Include the corresponding endorsed RAN1 CR in the LS to RAN2 if the CR can be endorsed at RAN1#110bis-e.
Corresponding draft CR in:
R1-2210572 Draft CR on HARQ-ACK feedback for PDSCH scheduled by DCI format 4_1 Moderator (Huawei), vivo, CATT, Lenovo
Agreement
· The draft CR in R1-2210572 is endorsed. Final CR is agreed in R1-2210701 (38.213, v17.3.0, Rel-17, CR#0389, Cat. F) and is attached to the final LS in R1-2210703.
R1-2210578 DRAFT LS on the RRC parameter for multicast HARQ-ACK feedback Huawei
Decision: The draft LS to RAN2 is endorsed. Final LS is approved in R1-2210703.
For issue 1-15 in R1-2210373
R1-2210505 Draft CR on RRC parameters alignment for HARQ-ACK CB for multicast Moderator (Huawei), CMCC
R1-2210570 Draft CR on RRC parameters alignment for HARQ-ACK CB for multicast Moderator (Huawei), CMCC
For alignment TS38.212 CR:
· The draft CR in R1-2210570 is endorsed for the editorial corrections.
For issue 1-8 in R1-2210373
R1-2210576 Draft CR on DAI counting for ‘dci-enabler’ in DCI indicating value 0 Moderator (Huawei), Langbo, Lenovo
Agreement
· The draft CR in R1-2210576 is endorsed. Final CR is agreed in R1-2210702 (38.213, v17.3.0, Rel-17, CR#0390, Cat. F).
Decision: As per email decision posted on Oct 15th,
R1-2210503 Draft CR on number of HARQ-ACK codebooks configurable for multicast Moderator (Huawei), CMCC
Agreement
· The draft CR in R1-2210503 is endorsed.
Final CR is agreed in R1-2210698 (38.212, v17.3.0, Rel-17, CR#0129, Cat. F).
R1-2210504 Draft CR on deleting redundant descriptions for HARQ-ACK CB types in UL DCI formats Moderator (Huawei), Lenovo
For alignment TS38.212 CR:
· The draft CR in R1-2210504 is endorsed for the editorial corrections.
R1-2210506 Draft CR on multiplexing NACK-only mode1 with others Moderator (Huawei), ZTE
Agreement
· The draft CR in R1-2210506 is endorsed.
Final CR is agreed in R1-2210699 (38.213, v17.3.0, Rel-17, CR#0387, Cat. F).
R1-2210374 FLS#3 on the HARQ-ACK related issues for Rel-17 NR MBS Moderator (Huawei)
For issue 1-5-2 in R1-2210374
R1-2210574 Draft CR on PUCCH resource determination of SPS multicast HARQ-ACK Moderator (Huawei)
Agreement
· The draft CR in R1-2210574 is endorsed in principle with the following revision:
o
“the UE determines the PUCCH resource from the sps-PUCCH-AN-List
configured provided for unicast SPS PDSCH receptions“
Final CR is agreed in R1-2210728 (38.213, v17.3.0, Rel-17, CR#0400, Cat. F).
For issue 1-6 in R1-2210374
R1-2210575 Draft CR on dci-enabler for Type1 HARQ-ACK CB for multicast Moderator (Huawei), Qualcomm, Lenovo
Agreement
· The draft CR in R1-2210575 is endorsed in principle.
Final CR is agreed in R1-2210775 (38.213, v17.3.0, Rel-17, CR#0409, Cat. F).
For issue 1-9 in R1-2210374
R1-2210750 Draft CR on multiplexing HARQ-ACK for DG and SPS multicast and unicast Moderator (Huawei), vivo
· The draft CR is postponed to RAN1#111
[110bis-e-R17-MBS-03] – Tuo (CMCC)
Email discussion for maintenance on mechanisms to support broadcast/multicast for RRC_CONNECTED/RRC_IDLE/RRC_INACTIVE UEs for the following issues in R1-2210371
- Issues 2-1, 2-2, 2-3, 2-4, 2-5, 2-6, 2-7 (including whether this is simply a spec alignment issue), 2-8, 2-9
- Editorial/alignment issues for providing to spec editors: 2-11, 2-12, 2-13, 2-14, 2-15
- Discuss for clarification of the issue (potentially discuss CR at RAN1#111, or conclude at RAN1#110bis-e that the issue is not essential): 2-10, 2-16, 2-17
- Discuss whether LS reply to R1-2208581 is needed for issue 2-18
- Check points: October 14, October 19
R1-2210399 Moderator’s summary#1 on scheduling related issues for Rel-17 NR MBS Moderator (CMCC)
R1-2210400 Moderator’s summary#2 on scheduling related issues for Rel-17 NR MBS Moderator (CMCC)
For issue 2-3 in R1-2210400
R1-2210511 Draft CR on PDCCH monitoring when overlapping with the rate matching pattern to TS 38.213 Moderator (CMCC), Qualcomm Incorporated, Huawei, HiSilicon, CBN, MediaTek
Agreement
· The draft CR in R1-2210511 is endorsed in principle.
Final CR is agreed in R1-2210647 (38.213, v17.3.0, Rel-17, CR#0383, Cat. F).
Decision: As per email decision posted on Oct 15th,
For issue 2-1 in R1-2210400
R1-2210446 Draft CR on the MBS reception type combinations to TS 38.202 Moderator (CMCC), MediaTek, Huawei, HiSilicon, CBN
Agreement
· The draft CR in R1-2210446 is endorsed in principle.
Final CR is agreed in R1-2210648 (38.202, v17.2.0, Rel-17, CR#0025, Cat. F).
Post meeting: MCC to clear CR header up and remove "[DRAFT]".
R1-2210447 Draft CR on the MBS reception type combinations to TS 38.213 Moderator(CMCC), Huawei, HiSilicon, CBN, ZTE
For alignment TS38.213 CR:
· The draft CR in R1-2210447 is endorsed for the editorial corrections.
For issue 2-2 in R1-2210400
R1-2210449 Draft CR on the max data rate for FDMed MBS and unicast to TS38.214 Moderator (CMCC), Huawei, HiSilicon, CBN, Qualcomm Incorporated
R1-2210649 CR on the max data rate for FDMed MBS and unicast to TS38.214 Moderator (CMCC), Huawei, HiSilicon, CBN, Qualcomm Incorporated
Agreement
· The draft CR in R1-2210449 is endorsed in principle.
Final CR is agreed in R1-2210649 (38.214, v17.3.0, Rel-17, CR#0360, Cat. F).
Post meeting: MCC to clear CR header up and remove "[DRAFT]".
R1-2210450 Draft CR on FDRA determination of multicast DCI formats to TS 38.212 Moderator (CMCC), Nokia, Nokia Shanghai Bell
For alignment TS38.212 CR:
· The draft CR in R1-2210450 is endorsed for the editorial corrections.
R1-2210451 Draft CR on CFR configuration for multicast to TS 38.213 Moderator (CMCC), ZTE, CATT
For alignment TS38.213 CR:
· The draft CR in R1-2210451 is endorsed for the editorial corrections.
R1-2209315 Draft CR on RRC parameters correction in TS 38.211 CMCC
For alignment TS38.211 CR:
· The draft CR in R1-2209315 is endorsed for the editorial corrections.
R1-2209316 Draft CR on RRC parameters correction in TS 38.212 CMCC
For alignment TS38.212 CR:
· The draft CR in R1-2209316 is endorsed for the editorial corrections.
R1-2209317 Draft CR on RRC parameters correction in TS 38.213 CMCC
For alignment TS38.213 CR:
· The draft CR in R1-2209317 is endorsed for the editorial corrections.
R1-2209318 Draft CR on RRC parameters correction in TS 38.214 CMCC
For alignment TS38.214 CR:
· The draft CR in R1-2209318 is endorsed for the editorial corrections.
For issue 2-1 in R1-2210400
R1-2210448 Draft CR on the MBS reception type combinations to TS 38.214 Moderator(CMCC), Huawei, HiSilicon, CBN
Agreement
· The draft CR in R1-2210448 is endorsed in principle.
Final CR is agreed in R1-2210768 (38.214, v17.3.0, Rel-17, CR#0368, Cat. F).
For issue 2-5 in R1-2210400
R1-2210452 Draft CR on SS0 availability for scheduling MBS to TS 38.213 Moderator (CMCC), Huawei, HiSilicon, CBN
R1-2210509 Draft CR on SS0 availability for scheduling MBS to TS 38.213 Moderator (CMCC), Huawei, HiSilicon, CBN
R1-2210645 Draft CR on SS0 availability for scheduling MBS to TS 38.213 Moderator (CMCC), Huawei, HiSilicon, CBN
Agreement
· The draft CR in R1-2210645 is endorsed in principle.
Final CR (38.213, v17.3.0, Rel-17, CR#0399, Cat. F) is agreed in:
R1-2210769 CR on SS0 availability for scheduling MBS to TS 38.213 Moderator (CMCC), Huawei, HiSilicon, CBN, ZTE
For issue 2-10 in R1-2210400
R1-2210510 Draft CR on definition of G-CS-RNTI for SPS group-common PDSCH retransmission to TS 38.213 Moderator (CMCC), CATT
R1-2210667 Draft CR on definition of G-CS-RNTI for SPS group-common PDSCH retransmission to TS 38.213 Moderator (CMCC), CATT
For alignment TS38.213 CR:
· The draft CR in R1-2210667 is endorsed in principle for the editorial corrections.
Final summary in R1-2210646.
R1-2212841 Session notes for 8.12 (Maintenance on NR Multicast and Broadcast Services) Ad-Hoc Chair (Huawei)
Endorsed and contents incorporated below.
[111-R17-MBS] – Jinhuan (Huawei)
To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
R1-2211641 Maintenance of broadcast and multicast for MBS ZTE
R1-2211844 Remaining Issues for RRC_CONNECTED UEs supporting MBS Nokia, Nokia Shanghai Bell
R1-2212267 Remaining issues on NR MBS MediaTek Inc.
R1-2212458 Remaining issues for Rel-17 MBS Huawei, HiSilicon, CBN
Maintenance on mechanisms to improve reliability for RRC_CONNECTED UEs
R1-2212618 FLS#1 on the HARQ-ACK related issues for Rel-17 NR MBS Moderator (Huawei)
R1-2212619 FLS#2 on the HARQ-ACK related issues for Rel-17 NR MBS Moderator (Huawei)
R1-2212620 FLS#3 on the HARQ-ACK related issues for Rel-17 NR MBS Moderator (Huawei)
For issues 1-1, 1-2 and 1-11
R1-2212776 Draft CR on interpretation of moreThanOneNackOnlyMode Moderator (Huawei), HiSilicon, CBN, Qualcomm, Samsung, vivo
Decision: The draft CR in R1-2212776 is endorsed. Final CR is agreed in:
R1-2212805 CR on interpretation of moreThanOneNackOnlyMode Moderator (Huawei), HiSilicon, CBN, Qualcomm, Samsung, vivo, ZTE
Further revised in R1-2212944 and agreed as rev2 after removing Samsung from the sourcing list in:
R1-2212974 CR on interpretation of moreThanOneNackOnlyMode Moderator (Huawei), HiSilicon, CBN, Qualcomm, vivo, ZTE
Decision: (38.213, v17.3.0, Rel-17, CR#0415rev2, Cat. F) is agreed.
Issue 1-1 moreThanOneNackOnlyMode and one HARQ-ACK bit
R1-2211643 Draft CR on NACK-only mode 1 and mode 2 with more than one bits ZTE
R1-2211847 Draft CR on NACK-only HARQ-ACK feedback Mode 1 Single TB Operation to TS38.213 Nokia, Nokia Shanghai Bell
R1-2211967 Draft CR on NACK-only based HARQ-ACK feedback mode 2 NTT DOCOMO, INC.
R1-2212460 Draft LS to RAN2 on correcting interpretation of moreThanOneNackOnlyMode Huawei, HiSilicon
R1-2212506 draft CR to 38.213 for NACK only mode 2 configuration Ericsson
R1-2212023 Maintenance on multicast-broadcast services Samsung
R1-2212622 Draft CR on interpretation of moreThanOneNackOnlyMode Moderator (Huawei)
Issue 1-2 PRI for NACK-only HARQ feedback
R1-2210983 Draft CR on PUCCH determination for NACK-only HARQ-ACK feedback to TS38.213 vivo
R1-2211642 Draft CR on PUCCH determination for NACK-only mode 1 with one bit ZTE
R1-2210865 Correction on PRI for NACK-only HARQ-ACK feedback to TS38.213 Huawei, HiSilicon, CBN
R1-2212266 Correction on PRI for NACK-only HARQ-ACK feedback to TS 38.213 MediaTek Inc.
R1-2212023 Maintenance on multicast-broadcast services Samsung
R1-2212623 Draft CR on PRI for NACK-only HARQ-ACK feedback to TS38.213 Moderator (Huawei)
Issue 1-3 Processing timeline for NACK-only HARQ feedback
R1-2212091 Draft CR on PDSCH processing time required to select PUCCH for NACK-only mode2 based multicast feedback Qualcomm Incorporated
R1-2212264 Correction on processing procedure timeline for MBS multicast NACK only mode 2 to TS38.214 MediaTek Inc.
R1-2212459 Correction on processing timeline for NACK-only mode2 to TS38.214 Huawei, HiSilicon, CBN
R1-2212504 draft CR to 38.214 for the NACK only timeline Ericsson
R1-2212390 Draft CR on processing timeline for NACK-only mode 2 for multicast Lenovo
R1-2212624 Draft CR on processing timeline for NACK-only mode2 to TS38.214 Moderator (Huawei), HiSilicon, CBN
R1-2212777 Draft CR on NACK-only mode 2 multicast feedback Moderator (Huawei), Qualcomm Incorporated
Decision: The draft CR in R1-2212777 is endorsed. Final CR (38.213, v17.3.0, Rel-17, CR#0416, Cat. F) is agreed in:
R1-2212806 CR on NACK-only mode 2 multicast feedback Moderator (Huawei), Qualcomm Incorporated
Issue 1-4 PUCCH resources determination for multiplexed DG and SPS multicast with different HARQ-ACK feedback modes
R1-2211644 Draft CR on multiplexing for the different HARQ-ACK reporting modes ZTE
R1-2212023 Maintenance on multicast-broadcast services Samsung
R1-2210863 Correction on PUCCH resource determination of multicast HARQ-ACK Huawei, HiSilicon, CBN, Nokia, Nokia Shanghai Bel
R1-2212625 Draft CR on PUCCH resource determination of multicast HARQ-ACK Moderator (Huawei), HiSilicon, CBN, Nokia, Nokia Shanghai Bell, ZTE, Samsung
Decision: The draft CR in R1-2212625 is endorsed. Final CR (38.213, v17.3.0, Rel-17, CR#0432, Cat. F) is agreed in R1-2212970.
Issue 1-5 Type2 HARQ-ACK codebook for DG/SPS multicast/unicast
R1-2212094 Darft CR on Type-2 codebook generation of DG and SPS multicast Qualcomm Incorporated
R1-2210864 Correction on multiplexing HARQ-ACK for DG and SPS multicast and unicast Huawei, HiSilicon, CBN
R1-2210980 Draft CR on multiplexing HARQ-ACK for DG and SPS multicast and unicast vivo
R1-2212023 Maintenance on multicast-broadcast services Samsung
R1-2212626 Draft CR on multiplexing HARQ-ACK for DG and SPS multicast and unicast Moderator (Huawei), HiSilicon, CBN, vivo, Samsung, Qualcomm
Decision: The draft CR in R1-2212626 is endorsed. Final CR (38.213, v17.3.0, Rel-17, CR#0433, Cat. F) is agreed in R1-2212971.
Issue 1-6 HARQ-ACK codebook generation for RRC disabled HARQ-ACK feedback
R1-2212023 Maintenance on multicast-broadcast services Samsung
R1-2212406 Correction on RRC based disabled and HARQ-ACK CB generation to TS 38.213 MediaTek Beijing Inc.
R1-2212389 Draft CR on HARQ-ACK codebook generation for RRC disabled HARQ-ACK feedback Lenovo
R1-2212627 Draft CR on HARQ-ACK codebook generation for RRC disabled HARQ-ACK feedback Moderator (Huawei), Lenovo, Samsung, MediaTek
R1-2212942 Draft CR on HARQ-ACK codebook generation for RRC disabled HARQ-ACK feedback Moderator (Huawei), Lenovo, Samsung, MediaTek, Qualcomm
Decision: The draft CR in R1-2212942 is endorsed. Final CR (38.213, v17.3.0, Rel-17, CR#0434, Cat. F) is agreed in R1-2212972.
Issue 1-7 Disabled HARQ-ACK and first PDSCH with DCI activation
R1-2212093 Draft CR on G-RNTI/G-CS-RNTI not configured with harq-FeedbackEnablerMulticast Qualcomm Incorporated
R1-2212324 Correction on first SPS PDSCH ASUSTeK
R1-2212628 Draft CR on not applying disabled HARQ-ACK to multicast SPS PDSCH without PDCCH scheduling Moderator (Huawei), Qualcomm Incorporated, ASUSTeK
Issue 1-8 NACK-only mode 2 multicast feedback
R1-2212095 Draft CR on NACK-only mode 2 multicast feedback Qualcomm Incorporated
R1-2212629 Draft CR on NACK-only mode 2 multicast feedback Moderator (Huawei), Qualcomm Incorporated
R1-2212778 Draft CR on NACK-only mode 2 multicast feedback Moderator (Huawei), Qualcomm Incorporated
R1-2212943 Draft CR on NACK-only mode 2 multicast feedback Moderator (Huawei), Qualcomm Incorporated
Decision: The draft CR in R1-2212943 is endorsed. Final CR (38.213, v17.3.0, Rel-17, CR#0435, Cat. F) is agreed in:
R1-2212973 CR on NACK-only mode 2 multicast feedback Moderator (Huawei), Qualcomm Incorporated, Samsung
Issue 1-9 PUCCH resources for SPS PDSCHs with NACK only feedback mode
R1-2210984 Draft CR on PUCCH resources for SPS PDSCHs with NACK only feedback mode vivo
R1-2212630 Draft CR on PUCCH resources for SPS PDSCHs with NACK only feedback mode Moderator (Huawei), vivo
Issue 1-10 Interpretation of moreThanOneNackOnlyMode
R1-2210981 Correction on PUCCH determination for NACK only mode 1 for SPS PDSCH vivo
R1-2211645 Draft CR on the NACK-only mode 1 ZTE
R1-2210866 Correction on interpretation of moreThanOneNackOnlyMode Huawei, HiSilicon, CBN
R1-2212631 Draft CR on alignment of moreThanOneNackOnlyMode Moderator (Huawei), HiSilicon, CBN, vivo, ZTE
Decision: The draft CR in R1-2212631 is endorsed. Final CR (38.213, v17.3.0, Rel-17, CR#0417, Cat. F) is agreed in:
R1-2212807 CR on alignment of moreThanOneNackOnlyMode Moderator (Huawei), HiSilicon, CBN, vivo, ZTE, Qualcomm
Issue 1-11 NACK-only mode1 for more than one G-RNTI
R1-2211849 Draft CR on Counting and Ordering of HARQ-ACK bits for NACK-only Feedback Mode 2 to TS38.213 Nokia, Nokia Shanghai Bell
R1-2212632 Draft CR on NACK-only mode1 applies to more than one G-RNTI Moderator (Huawei)
Merged to R1-2212776.
Issue 1-12 NACK-only mode2 for more than one G-RNTI
R1-2211657 Draft CR on multiple G-RNTIs for NACK-only feedback mode 2 CMCC
R1-2211848 Draft CR on NACK-only HARQ-ACK feedback Mode 2 for Multiple G-RNTIs to TS38.213 Nokia, Nokia Shanghai Bell
R1-2211966 Draft CR on NACK-only based feedback when multiple G-RNTIs are configured NTT DOCOMO, INC.
R1-2212357 Remaining Issues on NR MBS NEC
R1-2212505 draft CR to 38.213 for NACK only mode 2 configuration with multiple G-RNTI Ericsson
R1-2212391 Remaining issues on HARQ-ACK feedback for NR MBS Lenovo
R1-2212633 Draft CR on applying NACK-only mode 2 to more than one G-RNTI Moderator (Huawei)
No consensus for this meeting.
Issue 1-13 PTP retransmission for NACK-only
R1-2210867 Correction on retransmission schemes for MBS HARQ-ACK feedback to TS38.213 Huawei, HiSilicon, CBN
R1-2212507 draft CR to 38.213 for PTP retransmissions of PTM Ericsson
R1-2212634 Draft CR on retransmission schemes for MBS HARQ-ACK feedback to TS38.213 Moderator (Huawei)
No consensus for this meeting.
Issue 1-14 UL DAI applying to G-CS-RNTI DAI counting
R1-2211154 Correction on UL DAI applying to G-CS-RNTI DAI counting CATT
R1-2212635 Draft CR on UL DAI applying to G-CS-RNTI DAI counting Moderator (Huawei)
No consensus for this meeting.
Issue 1-15 Multicast HARQ-ACK
R1-2212298 Draft CR on multicast HARQ-ACK LG Electronics
R1-2212636 Draft CR on multicast HARQ-ACK Moderator (Huawei)
No consensus for this meeting.
Issue 1-16 Editorial (Correcting 0 bits to 0 bit in DCI format 4_2 in TS38.212)
R1-2211155 Draft editorial CR on DCI format 4_2 CATT
Issue 1-17 UE behavior for disabled HARQ for NTN multicast
R1-2212092 Draft CR on multicast PDSCH with a HARQ process with disabled HARQ-ACK feedback Qualcomm Incorporated
R1-2212508 draft CR to 38.213 for HARQ process enabling for MBS Ericsson
Issue 1-18 Type-3 HARQ-ACK codebook for NACK-only mode in MBS
R1-2211650 Draft CR on the Type-3 codebook for MBS ZTE
R1-2212189 Correction on Type-3 HARQ-ACK codebook for NACK-only mode in MBS Langbo
R1-2212637 Draft CR on Type-3 HARQ-ACK codebook for NACK-only mode for MBS Moderator (Huawei)
No consensus for this meeting.
Issue 1-19 MBS HARQ-ACK codebook retransmission
R1-2211146 Discussion on MBS supporting HARQ-ACK codebook retransmission CATT
R1-2211148 Draft CR on MBS supporting HARQ-ACK codebook retransmission CATT
Issue 1-20 MBS supporting deferring HARQ-ACK for SPS PDSCH
R1-2211147 Discussion on MBS supporting deferring HARQ-ACK for SPS PDSCH CATT
R1-2211149 Draft CR on MBS supporting deferring HARQ-ACK for SPS PDSCH CATT
Issue 1-21 DAI update for multicast DCI formats and Type-2 HARQ-ACK codebook
R1-2212388 Draft CR on DAI update for multicast DCI formats and Type-2 HARQ-ACK codebook Lenovo
R1-2212638 Draft CR on DAI update for multicast DCI formats and Type-2 HARQ-ACK codebook Moderator (Huawei), Lenovo
This issue implies a revision of the agreed CR in R1-2210702 (38.213, v17.3.0, Rel-17, CR#0390, Cat. F) from RAN1#110bis-e.
R1-2212829 CR on DAI counting for ‘dci-enabler’ in DCI indicating value 0 Moderator (Huawei), Langbo, Lenovo
Agreement
· R1-2212829 is endorsed in principle with the following change:
========= Start of TP =========
< Unchanged parts are omitted >
A value of the counter downlink assignment indicator (DAI) field in DCI formats denotes the accumulative number of {serving cell, PDCCH monitoring occasion}-pairs in which PDSCH receptions, excluding PDSCH receptions that provide only transport blocks for HARQ processes associated with disabled HARQ-ACK information if donwlinkHARQ-FeedbackDisabled is provided or PDSCH receptions scheduled by DCI formats associated with G-RNTI/G-CS-RNTI with disabled HARQ-ACK information, or HARQ-ACK information bits that are not in response for PDSCH receptions, associated with the DCI formats, excluding the SPS activation DCI, is present up to the current serving cell and current PDCCH monitoring occasion,
- first, if the UE indicates by type2-HARQ-ACK-Codebook support for more than one PDSCH reception on a serving cell that are scheduled from a same PDCCH monitoring occasion, in increasing order of the PDSCH reception starting time for the same {serving cell, PDCCH monitoring occasion} pair,
- second in ascending order of serving cell index, and
- third in ascending
order of PDCCH monitoring occasion index 
, where 
.
< Unchanged parts are omitted >
========= End of TP =========
Final CR (38.213, v17.3.0, Rel-17, CR#0390rev2, Cat. F) is agreed in R1-2212975.
Issue 1-22 Intra-UE multiplexing with NACK-only PUCCH
R1-2211651 Draft CR on intra-UE multiplexing with NACK-only PUCCH ZTE
R1-2212639 Draft CR on the cancellation procedure for the support of HARQ-ACK feedback for multicast Moderator (Huawei)
No consensus for this meeting.
Issue 1-23 DCI for enable/disable HARQ for MBS
R1-2212509 draft CR to 38.214 on DCI for enable/disable HARQ for MBS Ericsson
R1-2212640 Draft CR on DCI for enabling/disabling HARQ-ACK for MBS Moderator (Huawei)
No consensus for this meeting.
Issue 1-24 Overlapping of NACK only PUCCH and SR PUCCH
R1-2211040 Discussion on overlapping of NACK only PUCCH and SR PUCCH vivo
This issue implies a revision of the agreed CR in R1-2210730 (38.213, v17.3.0, Rel-17, CR#0402, Cat. F) from RAN1#110bis-e.
R1-2212945 CR on handling SR and NACK-only collision Moderator (Huawei), vivo
Decision: CR (38.213, v17.3.0, Rel-17, CR#0402r, Cat. F) is agreed.
Issue 1-25 Redundant descriptions for NACK only PUCCH transmission
R1-2210982 Draft CR on deleting redundant descriptions for NACK only PUCCH transmission vivo
Final summary in R1-2212621.
Maintenance on mechanisms to support broadcast/multicast for RRC_CONNECTED/RRC_IDLE/RRC_INACTIVE UEs
R1-2212373 Moderator’s summary#1 on scheduling related issues for Rel-17 NR MBS Moderator (CMCC)
R1-2212761 Moderator’s summary#2 on scheduling related issues for Rel-17 NR MBS Moderator (CMCC)
R1-2212762 Moderator’s summary#3 on scheduling related issues for Rel-17 NR MBS Moderator (CMCC)
Issue#1 FDM unicast PDSCH and GC-PDSCH
R1-2210985 Draft CR on FDM unicast PDSCH and multicast PDSCH to TS38.214 vivo
R1-2211649 Draft 214 CR on FDM reception ZTE
R1-2212510 draft CR to 38.214 for FDM SPS collision handling for MBS Ericsson
R1-2212511 Maintenance on NR Multicast and Broadcast Services Ericsson
R1-2211659 Clarification of FDMed unicast PDSCH and group-common PDSCH capability CMCC
R1-2211660 Draft CR on FDMed unicast PDSCH and group-common PDSCH CMCC
Agreement
It is clarified that for the FDMed unicast PDSCH and group-common PDSCH capability of RRC_CONNECTED UE, the unicast PDSCH and group-common PDSCH can only be dynamically scheduled. Further down-selection between the following:
· Opt 1: the unicast/multicast SPS retransmission PDSCH is included in the dynamically scheduled PDSCH for FDMed scheduling
o FFS: whether new UE capability is needed
· Opt 2: the unicast/multicast SPS retransmission PDSCH is NOT included in the dynamically scheduled PDSCH for FDMed scheduling
Issue#2 Collision handling between SPS and DG for MBS
R1-2211661 Draft CR on SPS and dynamic scheduling PDSCH(s) collision for MBS CMCC
Issue#3 SS0 PDCCH monitoring occasion determination for scheduling MBS
R1-2211658 Draft CR on broadcast search space monitoring occasion determination CMCC
R1-2212707 Draft CR on broadcast search space monitoring occasion determination Moderator (CMCC)
Decision: The draft CR in R1-2212707 is endorsed. Final CR (38.213, v17.3.0, Rel-17, CR#0429, Cat. F) is agreed in R1-2212922.
Issue#4 DCI size alignment
R1-2211150 Discussion on format 4_0/4_1 DCI size alignment to CSS format 1_0 CATT
R1-2211151 Draft CR on format 4_0 DCI size alignment to CSS format 1_0 CATT
R1-2211152 Draft CR on format 4_1 DCI size alignment to CSS format 1_0 CATT
R1-2211153 Draft CR on configuration limitation of DCI size DCI format 4_2 CATT
R1-2212772 Draft CR on format 4_0 DCI size alignment in SCell Moderator (CMCC), CATT
R1-2212921 Draft CR on format 4_0 DCI size alignment in SCell Moderator (CMCC), CATT, ZTE
Decision: The draft CR in R1-2212921 is endorsed. Final CR (38.212, v17.3.0, Rel-17, CR#0133, Cat. F) is agreed in:
R1-2212985 CR on format 4_0 DCI size alignment in SCell Moderator (CMCC), CATT, ZTE, MediaTek
Issue#5 Terms of G-RNTI/MTCH
R1-2211646 Draft 212 CR on terms of G-RNTI ZTE
R1-2211647 Draft 213 CR on terms of G-RNTI ZTE
R1-2211648 Draft 214 CR on terms of G-RNTI ZTE
R1-2211662 Draft CR on terms of MTCH used in TS 38.213 CMCC
R1-2211663 Draft CR on terms of MTCH used in TS 38.214 CMCC
Agreement
· The draft CR in R1-2212708 is endorsed for the editorial corrections for TS38.212.
o R1-2212708 Draft CR on terms of G-RNTI and MTCH in TS38.212 Moderator (CMCC), ZTE
· The draft CR in R1-2212709 is endorsed for the editorial corrections for TS38.213.
o R1-2212709 Draft CR on terms of G-RNTI and MTCH in TS38.213 Moderator (CMCC), ZTE
· The draft CR in R1-2212710 is endorsed for the editorial corrections for TS38.214.
o R1-2212710 Draft CR on terms of G-RNTI and MTCH in TS38.214 Moderator (CMCC), ZTE
Issue#6 Editorial CRs
R1-2211155 Draft editorial CR on DCI format 4_2 CATT
R1-2211656 Draft CR on MCCH change notification CMCC
R1-2210985 Draft CR on FDM unicast PDSCH and multicast PDSCH to TS38.214 vivo
R1-2212711 Draft CR on MCCH change notification Moderator (CMCC)
R1-2212712 Draft editorial CR on G-CS-RNTI Moderator (CMCC), vivo
Agreement
· The draft CR in R1-2212711 is endorsed for the editorial corrections for TS38.212.
· The draft CR in R1-2212712 is endorsed for the editorial corrections for TS38.214.
Issue#7 Max data rate/LBRM upper bound of FDM case (issue#7 in R1-22xxxxx)
R1-2212090 Remaining issues for NR MBS Qualcomm Incorporated
Conclusion
In case of FDMed unicast and MBS PDSCHs, the max data rate and upper bound of TBS LBRM for allocated TB(s) in a 14 consecutive-symbol duration is based on the unicast parameters.
Issue#8 Rate-matching pattern for broadcast
R1-2212265 Correction on RM pattern for MBS broadcast reception to TS38.214 MediaTek Inc.
Decision: The draft CR in R1-2212265 is endorsed. Final CR (38.214, v17.3.0, Rel-17, CR#0389, Cat. F) is agreed in:
R1-2212986 CR on rate-matching pattern for MBS broadcast reception Moderator (CMCC), MediaTek
Issue#9 timeDurationForQCL
R1-2212299 Draft CR on NR MBS LG Electronics
Final summary in R1-2212987.
R1-2302060 Session notes for 8.12 (Maintenance on NR Multicast and Broadcast Services) Ad-Hoc Chair (Huawei)
[112-R17-MBS] – Jinhuan (Huawei)
To be used for sharing updates on online/offline schedule, details on what is to be discussed in online/offline sessions, tdoc number of the moderator summary for online session, etc
From AI 5
R1-2300015 LS on SPS configuration for unicast and multicast RAN2, ASUSTEK
R1-2301994 Discussion related to LS on unicast and multicast SPS ASUSTeK
Presented in Tuesday session
R1-2302167 Further discussion related to LS on unicast and multicast SPS Moderator (ASUSTeK)
From Thursday session
R1-2302168 [Draft] Reply LS on SPS configuration for unicast and multicast Moderator (ASUSTeK)
Decision: The draft LS reply in R1-2302168 is endorsed. Final LS is approved in R1-2302209.
Maintenance on mechanisms to improve reliability for RRC_CONNECTED UEs
R1-2301917 FLS#1 on the HARQ-ACK related issues for Rel-17 NR MBS Moderator (Huawei)
Presented in Tuesday session
R1-2301918 FLS#2 on the HARQ-ACK related issues for Rel-17 NR MBS Moderator (Huawei)
Presented in Thursday session
Issue 1-1 NACK-only mode regarding moreThanOneNackOnlyMode
R1-2301238 Correction on HARQ-ACK reporting for the “NACK-only” mode in MBS Samsung
Issue 1-2 Type-1 CB generation
R1-2301450 Draft CR on the generation of the type1 HARQ-ACK codebook ZTE
R1-2301920 Draft CR on Type-1 HARQ-ACK codebook multiplexing for unicast and multicast Moderator (Huawei)
Issue 1-3 3rd DAI field for two CBs
R1-2300639 Correction on DCI field when two HARQ-ACK codebooks are configured CATT, CBN
R1-2301921 Draft CR on aligning DCI sizes when configuring two HARQ-ACK codebooks for multicast Moderator (Huawei)
From Tuesday session
Agreement
· The draft CR in R1-2301921 is endorsed. Final CR (Rel-17, 38.212, CR0135, Cat F) is agreed in
R1-2302039 CR on aligning DCI sizes when configuring two HARQ-ACK codebooks for multicast Moderator (Huawei), CATT
Issue 1-4 Disabled HARQ-ACK not applied to SPS ac/dea
R1-2300075 Draft CR on not applying disabled HARQ-ACK to multicast SPS PDSCH without PDCCH scheduling Huawei, HiSilicon, CBN
R1-2300427 Draft CR on not applying disabled HARQ-ACK to multicast SPS PDSCH activation and deactivation vivo
R1-2300925 Draft CR on Disabled HARQ-ACK Not Applied to SPS Activation to TS38.213 Nokia, Nokia Shanghai Bell
R1-2301088 Draft CR on HARQ-ACK feedback for multicast SPS activation/deactivation Lenovo
R1-2301390 Draft CR on first HARQ feedback mode for multicast SPS activation/deactivation Qualcomm Incorporated
R1-2301462 Correction on HARQ feedback for multicast SPS (de)activation ASUSTeK
R1-2301673 Draft CR to 38.213 for the use of HARQ with multicast SPS activation and release Ericsson
R1-2301452 Draft 213 CR on feedback mode for SPS ZTE
R1-2301713 Remaining issues for Rel-17 MBS Huawei, HiSilicon, CBN
R1-2301787 Corrections on HARQ-ACK for multicast SPS MediaTek Inc. (rev of R1-2301613)
R1-2301922 Draft CR on not applying disabled HARQ-ACK for multicast SPS activation/deactivation Moderator (Huawei)
Issue 1-5 PTP retransmission
R1-2300076 Draft CR on retransmission schemes for MBS HARQ-ACK feedback to TS38.213 Huawei, HiSilicon, CBN
R1-2301672 Draft CR to 38.213 for PTP retransmissions of PTM Ericsson
R1-2301923 Draft CR on retransmission schemes for MBS Moderator (Huawei)
Issue 1-6 K1 indication/config
R1-2300637 Discussion on HARQ ACK timing description for multicast CATT,CBN
R1-2300638 Draft CR on HARQ ACK timing description for multicast CATT,CBN
R1-2300633 Discussion on Type1 HARQ codebook generation for fdmed-ReceptionMulticast CATT,CBN
R1-2300634 Draft CR on Type1 HARQ codebook generation for fdmed-ReceptionMulticast CATT,CBN
R1-2300635 Draft CR on K1 generation for type1-Codebook-GenerationMode CATT,CBN
R1-2301786 Remaining issues on NR MBS MediaTek Inc. (rev of R1-2301612)
R1-2301789 Correction on K1 determination for multicast Type-1 CB MediaTek Inc.
R1-2301924 Draft CR on HARQ-ACK timing for multicast Moderator (Huawei)
From Tuesday session
Agreement
The draft CR in R1-2301924 is endorsed. Final CR (38.213, Rel-17, CR#0440, Cat. F) is agreed in
R1-2302040 CR on HARQ-ACK timing for multicast Moderator (Huawei), CATT, MediaTek, ZTE, Qualcomm
Issue 1-7 UL-DAI for SPS
R1-2300077 Draft CR on UL DAI applying to G-CS-RNTI DAI counting Huawei, HiSilicon, CBN
R1-2301240 Correction on multiplexing Type-2 HARQ-ACK codebook in a PUSCH Samsung
R1-2301925 Draft CR on multiplexing Type-2 HARQ-ACK codebook in a PUSCH Moderator (Huawei)
From Tuesday session
Agreement
The draft CR in R1-2301925 is endorsed with the following modification:
·
if the UE multiplexes HARQ-ACK
information associated with more than one G-RNTIs for multicast or more
than one G-CS-RNTIs, the value of the DAI field 
is applicable to each of the more than one G-RNTIs for
multicast or each of the more than one
G-CS-RNTIs
Final CR (38.213, Rel-17, CR#0441, Cat. F) is agreed in
R1-2302041 CR on multiplexing Type-2 HARQ-ACK codebook in a PUSCH Moderator (Huawei), HiSilicon, CBN, Samsung
Issue 1-8 PUCCH resources for mux HARQ-ACK
R1-2300078 Draft CR on multicast HARQ-ACK Huawei, HiSilicon, CBN
R1-2301104 Draft CR on multicast HARQ-ACK LG Electronics
R1-2300426 Correction on PUCCH determination for NACK only mode 1 for SPS PDSCH vivo
R1-2301455 Draft 213 CR on PUCCH resource configuration for MBS ZTE
R1-2301926 Draft CR on PUCCH resources for multiplexing multicast HARQ-ACK Moderator (Huawei)
From Thursday session
Agreement
The draft CR in R1-2301926 is endorsed. Final CR (38.213, Rel-17, CR#0453, Cat. F) is agreed in
R1-2302206 CR on PUCCH resources for multiplexing multicast HARQ-ACK Moderator (Huawei), vivo
Issue 1-9 Type3 CB for Ucast/Mcast
R1-2300428 Draft CR on type 3 HARQ-ACK codebook for unicast and multicast vivo
R1-2301089 Draft CR on multicast HARQ-ACK information in a Type-3 HARQ-ACK codebook Lenovo
R1-2301458 Draft CR on the Type-3 codebook for MBS ZTE
R1-2301927 Draft CR on clarifying Type-3 HARQ-ACK codebook is supported for multicast Moderator (Huawei)
From Tuesday session
Agreement
The draft CR in R1-2301927 is endorsed for inclusion in an alignment CR for TS38.213.
Issue 1-10 disabled HARQ for NTN multicast
R1-2301388 Remaining issues for NR MBS Qualcomm Incorporated
R1-2301389 Draft CR on G-RNTI/G-CS-RNTI not configured with harq-FeedbackEnablerMulticast Qualcomm Incorporated
R1-2301674 Draft CR to 38.213 for HARQ process enabling for MBS Ericsson
From Thursday session
Conclusion
It is RAN1 understanding that RAN1 specifications allow the UE to operate at the same time with NTN and MBS for HARQ-ACK reporting. No RAN1 CR is needed.
Issue 1-11 SR+NACK-PUCCH+other PUCCH/PUSCH
R1-2300430 Discussion on overlapping among NACK PUCCH, SR PUCCH and other PUCCH/PUSCH vivo
R1-2300431 Draft CR on overlapping among NACK PUCCH, SR PUCCH and other PUCCH/PUSCH vivo
R1-2301241 Correction on multiplexing NACK-only HARQ-ACK and CSI and SR in a PUCCH Samsung
Issue 1-12 PUCCH resources for SPS NACK-only
R1-2301454 Draft 213 CR on PUCCH resource for SPS PDSCH for MBS for NACK-only mode ZTE
R1-2302166 Draft CR on PUCCH resource for UE configured with NACK-only mode2 for SPS Moderator (Huawei)
From Thursday session
Agreement
The draft CR in R1-2302166 is endorsed. Final CR (38.213, Rel-17, CR#0452, Cat. F) is agreed in
R1-2302205 CR on PUCCH resource for UE configured with NACK-only mode2 for SPS Moderator (Huawei), ZTE
Issue 1-13 >2 bits for SPS NACK-only mode2
R1-2300429 Discussion on more than 2bits HARQ-ACK for SPS PDSCHs with NACK only feedback mode vivo
Issue 1-14 NACK-only mode2 for >1 G-RNTI
R1-2301030 Draft CR on Counting and Ordering of HARQ-ACK bits for NACK-only Feedback Mode 2 to TS38.213 Nokia, Nokia Shanghai Bell
R1-2301475 Draft CR to support NACK-only feedback with multiple G-RNTIs NTT DOCOMO, INC.
R1-2301239 Correction on supporting multiple G-RNTIs/G-SC-RNTIs for the “NACK-only” mode in MBS Samsung
R1-2301671 Draft CR to 38.213 for NACK only mode 2 configuration with multiple G-RNTI Ericsson
R1-2301786 Remaining issues on NR MBS MediaTek Inc. (rev of R1-2301612)
R1-2301788 Correction on HARQ-ACK for multicast NACK only mode 2 MediaTek Inc. (rev of R1-2301614)
Issue 1-15 Intra-UE HARQ-ACK
multiplexing
R1-2301456 Draft CR on intra-UE multiplexing for MBS ZTE
R1-2301457 Draft CR on intra-UE multiplexing with NACK-only PUCCH ZTE
Issue 1-16 Same ‘dci-enabler’ indication
R1-2301675 Draft CR to 38.214 on DCI for enable/disable HARQ for MBS Ericsson
Issue 1-17 Type-1 CB for >1 multicast SPS
R1-2301715 Draft CR on HARQ-ACK codebook generation for multicast SPS Huawei, HiSilicon, CBN
Issue 1-18 RRC parameters correction
R1-2301449 Draft editorial CR on RRC signaling for Type-1 codebook for MBS ZTE
Issue 1-19 Processing timeline for NACK-only
R1-2301090 Draft CR on processing timeline for NACK-only mode 2 for multicast Lenovo
Final summary in R1-2301919.
Maintenance on mechanisms to support broadcast/multicast for RRC_CONNECTED/RRC_IDLE/RRC_INACTIVE UEs
R1-2301826 Moderator’s summary#1 on scheduling related issues for Rel-17 NR MBS Moderator (CMCC)
Presented in Tuesday session
R1-2301827 Moderator’s summary#2 on scheduling related issues for Rel-17 NR MBS Moderator (CMCC)
From Thursday session
Issue#2-1 FDMed unicast PDSCH and GC-PDSCH
R1-2300423 Discussion on SPS PDSCH retransmission for FDMed unicast PDSCH and multicast PDSCH vivo
R1-2300424 Draft CR on FDMed unicast PDSCH and multicast PDSCH to TS38.214 vivo
R1-2300924 Remaining Issues on Group Scheduling Mechanisms for RRC_CONNECTED Ues supporting MBS Nokia, Nokia Shanghai Bell
R1-2301033 Draft CR on SPS PDSCH collisions with DG PDSCH for TS38.214 Nokia, Nokia Shanghai Bell
R1-2300980 Draft CR on FDMed unicast PDSCH and group-common PDSCH CMCC
R1-2301242 Correction on FDMed unicast and multicast PDSCH receptions Samsung
R1-2301453 Draft 214 CR on FDM reception ZTE
R1-2301676 Maintenance on NR Multicast and Broadcast Services Ericsson
R1-2301669 Draft CR on UE behavior for FDMed unicast and SPS retransmission for multicast Ericsson
R1-2301700 Draft CR on FDM unicast PDSCH and GC-PDSCH Huawei, HiSilicon, CBN
From Tuesday session
Agreement
Opt 1 in the following agreement is adopted.
Agreement
It is clarified that for the FDMed unicast PDSCH and group-common PDSCH capability of RRC_CONNECTED UE, the unicast PDSCH and group-common PDSCH can only be dynamically scheduled. Further down-selection between the following:
· Opt 1: the unicast/multicast SPS retransmission PDSCH is included in the dynamically scheduled PDSCH for FDMed scheduling
o FFS: whether new UE capability is needed
· Opt 2: the unicast/multicast SPS retransmission PDSCH is NOT included in the dynamically scheduled PDSCH for FDMed scheduling
R1-2302076 Draft CR on FDMed unicast PDSCH and group-common PDSCH Moderator (CMCC), vivo, Samsung, ZTE, Ericsson, Huawei, HiSilicon, CBN
From Thursday session
Agreement
· The TP below for section 5.1 of TS38.214 is endorsed:
------- Start of TP -------
5.1 UE procedure for receiving the physical downlink shared channel
========================= Unchanged parts =========================
If the UE is
capable of receiving FDMed unicast and multicast PDSCH per slot per carrier,
the UE shall be able to decode a PDSCH scheduled by a DCI format with
C-RNTI/ or a
PDSCH scheduled for a
retransmission of a TB by a DCI format by
a DCI formata retransmission
PDSCH scheduled with CS-RNTI
and a PDSCH scheduled by a DCI format with G-RNTI for
multicast/ or a
retransmission PDSCH scheduled a PDSCH scheduledby
a DCI format for a
retransmission of a TB by a DCI format with G-CS-RNTI
that partially or fully overlap in time in non-overlapping PRBs. If the UE is
capable of receiving FDMed unicast and broadcast PDSCH per slot per carrier,
the UE shall be able to decode a PDSCH scheduled by a DCI format with
C-RNTI/ or a
PDSCH scheduled for a retransmission of a TB by a DCI format by
a DCI formata retransmision PDSCH scheduled with
CS-RNTI and a PDSCH scheduled with G-RNTI for broadcast/MCCH-RNTI
that partially or fully overlap in time in non-overlapping PRBs.
========================= Unchanged parts =========================
------- End of TP -------
R1-2302190 Draft CR on FDMed unicast PDSCH and group-common PDSCH Moderator (CMCC), vivo, Samsung, ZTE, Ericsson, Huawei, HiSilicon, CBN
Decision: The draft CR in R1-2302190 is endorsed. Final CR (Rel-17, 38.214, CR0410, Cat F) is agreed in R1-2302191.
Issue#2-2 Collision handling between SPS and DG for MBS
R1-2300425 Draft CR on SPS and dynamic scheduling PDSCH(s) collision for MBS vivo
R1-2300981 Draft CR on SPS and dynamic scheduling PDSCH(s) collision for MBS CMCC
R1-2301670 Draft CR on collision handling for SPS and dynamic scheduling PDSCH Ericsson
R1-2301701 Draft CR on collision handling between SPS and DG for MBS Huawei, HiSilicon, CBN
R1-2301992 Draft CR on SPS and dynamic scheduling PDSCH(s) collision for MBS Moderator (CMCC), vivo, Ericsson, Huawei, HiSilicon, CBN
From Tuesday session
Agreement
The draft CR in R1-2301992 is endorsed. Final CR (Rel-17, 38.214, CR0398, Cat F) is agreed in R1-2302133.
Issue#2-3 broadcast PDCCH monitoring
R1-2301451 Draft 213 CR on broadcast PDCCH monitoring in active DL BWP ZTE
From Tuesday session
Agreement
The draft CR in R1-2301451 is endorsed. Comeback for final CR after revising the cover sheet and the CR template. Final CR (Rel-17, 38.213, CR0446, Cat F) is agreed in
R1-2302134 CR on broadcast PDCCH monitoring in active DL BWP Moderator (CMCC), ZTE
Issue#2-4 rate match patter number for broadcast
R1-2301622 Correction on rate match patter number for MBS broadcast reception MediaTek Inc.
R1-2301993 Draft CR on rate matching pattern number for MBS broadcast reception Moderator (CMCC), MediaTek
From Thursday session
Agreement
The draft CR in R1-2301993 is endorsed. Final CR (Rel-17, 38.214, CR0411, Cat F) is agreed in
R1-2302192 CR on rate matching pattern number for MBS broadcast reception Moderator (CMCC), MediaTek
MCC post meeting: Delete "draft" in title before submission to plenary.
Issue#2-5 Joint release of multiple multicast SPS
R1-2301105 Draft CR on sps-ConfigDeactivationStateList LG Electronics
From Thursday session
Agreement
Multicast DCI cannot be used for
· joint SPS unicast and SPS multicast release
· joint SPS unicast release
· FFS: joint SPS multicast release
Issue#2-6 SPS activation/release PDCCH validation
R1-2300978 Draft CR on SPS release PDCCH validation of DCI with CS-RNTI CMCC
R1-2300979 Draft CR on PDCCH validation for single multicast SPS CMCC
R1-2301714 Draft CR on PDCCH validation for multicast SPS Huawei, HiSilicon, CBN
Issue#2-7 parameter maxNrofCodeWordsScheduledByDCI for multicast
R1-2300632 Draft CR on the parameter maxNrofCodeWordsScheduledByDCI for multicast CATT,CBN
From Tuesday session
Agreement
· The draft CR in R1-2300632 is endorsed for the editorial corrections for TS38.212.
Issue#2-8 G-RNTI/G-CS-RNTI configuration
R1-2301087 Draft CR on configuration of G-RNTI / G-CS-RNTI per serving cell Lenovo
From Thursday session
Conclusion
No correction is needed for Issue#2-8 in Rel-17.
Issue#2-9
Editorial CRs to TS 38.212:
R1-2300631 Draft editorial CR on DCI format 4_2 in TS 38.212 CATT,CBN
From Tuesday session
Agreement
· The draft CR in R1-2300631 is endorsed for the editorial corrections for TS38.212.
Editorial CRs to TS 38.213:
R1-2300924 Remaining Issues on Group Scheduling Mechanisms for RRC_CONNECTED Ues supporting MBS Nokia, Nokia Shanghai Bell
R1-2301032 Draft correction on monitoring for DCI format 4_0 on Type0-PDCCH CSS to TS 38.213 Nokia, Nokia Shanghai Bell
From Tuesday session
Agreement
· The draft CR in R1-2301032 is endorsed for the editorial corrections for TS38.213.
Editorial CRs to TS 38.214:
R1-2300636 Draft editorial CR on resource allocation table for multicast in 38.214 CATT,CBN
From Tuesday session
Agreement
· The draft CR in R1-2300636 is endorsed for the editorial corrections for TS38.214.
